Bug#931444: ncdu: progress dialog: for dirs with many files, total items can almost overlap size

[Paul Wise]

Package: ncdu
Version: 1.13-1+b1
Severity: minor

For directories that have many subdirectories and many files, in the
ncdu progress dialog the total items count can encroach on and almost
overlap the total size count:

   Total items: 20161797size: 123.4 GiB

I would expect that the code should instead always insert at least one
space between items and size but it seems like the location of the size
item is hard-coded:

https://sources.debian.org/src/ncdu/1.13-1/src/dir_common.c/?hl=125#L109

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

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

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

ncdu recommends no packages.

ncdu suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#851547: gnome-shell: under Wayland, alt-tab switcher fails when using focus-follow-mouse

[Antonis Christofides]

Apparently this is the upstream bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=739718

Bug#931443: menu: corrected Romanian translation for su-to-root

[andreimpopescu]

Package: menu
Version: 2.1.47
Severity: wishlist
Tags: l10n patch
X-Debbugs-CC: debian-l10n-roman...@lists.debian.org

Dear Maintainer,

Attached a corrected Romanian translation for su-to-root.

Please kindly include on your next update.

Best regards,
Andrei

- Forwarded message from Cristian Secară  -

Date: Thu, 4 Jul 2019 18:44:46 +0300
From: Cristian Secară 
To: debian-l10n-roman...@lists.debian.org
Subject: fișierul .po de la menu_2.1.47_ro
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-w64-mingw32)

În data de Tue, 2 Jul 2019 09:07:39 +0300, andreimpope...@gmail.com a scris:

> Vă rog trimiteți un .po actualizat la 
> debian-l10n-roman...@lists.debian.org și mă ocup eu de actualizare. 

Atașat.

Cristi

-- 
Cristian Secară
http://www.secarica.ro


- End forwarded message -

-- 
http://wiki.debian.org/FAQsFromDebianUser


menu_2.1.47_ro.po.gz
Description: Binary data


signature.asc
Description: PGP signature

Bug#931442: gnome-boxes: Debian netinst download should use amd64 instead of i386

[Paul Wise]

Package: gnome-boxes
Version: 3.31.90-2
Severity: normal

The menu for creating a new virtual machines has this entry:

   Debian 9 i686 (netinst)
   Debian Project

This should be using amd64 instead, since it is better than i386.

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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-ba  0.30.1-2
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4
ii  libfreerdp2-2  2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2
ii  libgovirt2 0.3.4-3.1
ii  libgtk-3-0 3.24.5-1
ii  libgtk-vnc-2.0-0   0.9.0-1.1
ii  libgudev-1.0-0 232-2
ii  libosinfo-1.0-01.2.0-1
ii  libosinfo-bin  1.2.0-1
ii  libpango-1.0-0 1.42.4-6
ii  librest-0.7-0  0.8.1-1
ii  libsecret-1-0  0.18.7-1
ii  libsoup2.4-1   2.64.2-2
ii  libspice-client-glib-2.0-8 0.35-2
ii  libspice-client-gtk-3.0-5  0.35-2
ii  libtracker-sparql-2.0-02.1.8-2
ii  libusb-1.0-0   2:1.0.22-2
ii  libvirt-daemon 5.0.0-4
ii  libvirt-glib-1.0-0 2.0.0-1
ii  libvte-2.91-0  0.54.2-2
ii  libwebkit2gtk-4.0-37   2.24.2-1
ii  libwinpr2-22.0.0~git20190204.1.2693389a+dfsg1-1
ii  libxml22.9.4+dfsg1-7+b3
ii  mtools 4.0.23-1
ii  tracker2.1.8-2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:3.1+dfsg-8

gnome-boxes suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#931286: jinja2 missed dependency

[sergio]

Confirm this bug.

Must depend on python3-jinja2.

-- 
sergio.

Bug#748962: texlive-bastexlive-base: fmtutil-sys --all may not return error exit code under low free space condition.

[Norbert Preining]

Hi Hilmar,

> Just curious: what is the status here? The repo does not exist any more.
> Seems to be migrated to perl since 2017 = Debian 9. I also noticed some
> code, which returns exit code > 0 in case of failure.

Yes, fmtutil the Perl variant is now the standard in TeX Live.

> Can we close?

No idea, sorry. I would say yes, but I haven't tested on a full disk.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#767871: tex4ht: htlatex cannot find latex

[Norbert Preining]

On Thu, 04 Jul 2019, Hilmar Preuße wrote:
> of all cases. I tend to add suggest: texlive-latex-base to
> texlive-plain-generic.

I would say depends is also fine. 

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#929369: ITP: ruby-referer-parser-- Library for extracting marketing attribution data from referer URLs

[Samyak Jain]

retitle 929369 ITP: ruby-referer-parser -- Library for extracting marketing
attribution data from referer URLs
Bug #929369 [wnpp] ITP: ruby-referer-parser-- Library for extracting
marketing attribution data from referer URLs
Changed Bug title to 'ITP: ruby-referer-parser -- Library for extracting
marketing attribution data from referer URLs  ' from 'ITP:
ruby-referer-parser-- Library for extracting marketing attribution data
from referer URLs'.

Bug#931389: LXQt: SDDM does not start

[Kevin Williams]

On 7/4/19 11:21 AM, Steve McIntyre wrote:
> Hi Kevin,
> 
> Thanks for giving us feedback.
> 
> On Wed, Jul 03, 2019 at 07:11:15PM +, Kevin Williams wrote:
>> Package: installation-reports
>>
>> Boot method: ISO image
>> Image version:
>> https://cdimage.debian.org/cdimage/buster_di_rc3/amd64/iso-cd/debian-buster-DI-rc3-amd64-netinst.iso
>> Date: 2019-07-03 1200 CDT
>>
>> Machine: Hyper-V on Win10 1903
>> Processor: Intel Core i7-3770
>> Memory: 2 GB
>> Partitions:
>>
>> udev devtmpfs968968  0   968968  0%  /dev
>> tmpfstmpfs   197744  3268194476  2%  /run
>> /dev/sda1ext449278612 42605344   9%  /
>> tmpfstmpfs   988708  7788980920  1%  /dev/shm
>> tmpfstmpfs   51200   51200%  /run/lock
>> tmpfstmpfs   988708  0   988708  0%  /sys/fs/cgroup
>> tmpfstmpfs   197740  8   197732  1%  /run/user/1000
> ...
> 
>> Comments/Problems:
>>
>> If I tell tasksel to install the desktop environment + LXQt, sddm will
>> not start, but startx will bring up the GUI.  If I instead have it
>> install MATE or LXDE, a GUI login screen comes up.
>>
>> I have not tried other DEs yet.
> 
> That's odd. I've just done a test installation of lxqt here in
> qemu/kvm using that image and I can't reproduce your problem - see
> 
>https://www.einval.com/~steve/tmp/lxqt-rc3.png
> 
> from straight after boot. Could you give us a copy of your
> installation syslog please?
> 

Sure.  It's too big for pastebin, so here it is:
https://mega.nz/#!OFYiDYST!6rvFjxgnwVangqm_5TXvoWt-mcnBWruuqq_Tn2rdXls

Since I made the report, I made a Hyper-V VM with a fresh install of 
Buster/KDE and it's got the same behavior.  Possibly sddm and Hyper-V 
don't get along?  No troubles with DEs that use lightdm.

Bug#931266: e2fsprogs: Build-Depends on udev and systemd on non-Linux architectures

[Theodore Ts'o]

Control: tags -1 +pending

On Sat, Jun 29, 2019 at 10:48:35PM +0100, James Clarke wrote:
> As of the above version, e2fsprogs Build-Depends on udev and systemd
> (and cron too which, whilst somewhat perplexing, is not the issue here),
> thereby rendering its build dependencies unsatisfiable on non-Linux
> architectures, namely GNU/kFreeBSD and GNU/Hurd (the latter being
> particularly important given it uses ext2fs as its filesystem). I went
> digging to see why this was but the commit[1] that added it isn't any
> more enlightening. I haven't tried building it without those packages, but can
> only assume the upstream code still works without udev and systemd. Can we
> please have this fixed in Debian so e2fsprogs builds everywhere again?

Thanks for reporting this!  The udev, systemd, and cron packages are
only needed to so the e2scrub scripts will be properly configured, and
e2scrub only works for Linux systems (since it relies on Linux's LVM
system).

I'll fix this for the next release.

- Ted

Bug#931440: wireguard module needs signing to work with secureboot

[hello i'm a lizard]

Package: wireguard
Version: 0.0.20190702-1
Severity: important

The wireguard kernel module installed by wireguard-dkms doesn't appear to be
signed and is therefore unusable on a secureboot system (without me figuring
out how the whole mok key thing works and manually signing it myself). Since
debian is building and packaging a signed kernel, could you also do this for
this module?

error messages:

[   18.375387] Lockdown: Loading of unsigned modules is restricted; see
https://wiki.debian.org/SecureBoot

# modprobe wireguard
modprobe: ERROR: could not insert 'wireguard': Required key not available

Thanks!



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/32 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)
LSM: AppArmor: enabled

Versions of packages wireguard depends on:
ii  wireguard-dkms   0.0.20190702-1
ii  wireguard-tools  0.0.20190702-1

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

Bug#931438: reportbug: While sending an installation-report no checklist was presented

[Alexandros Prekates]

Package: reportbug
Version: 7.5.2
Severity: normal

Dear Maintainer,

Execute:
$ reportbug installation-reports

The issue reported is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931437

An empty check list in included but NO check list
was presented to my from reportbug.

Also , i could paste a cd image url when prompted.
I had to write it manualy.



-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/chomwitt/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui gtk2
realname "Alexandros Prekates"
email "apreka...@posteo.net"
smtphost "posteo.de"
smtpuser "apreka...@posteo.net"
smtptls

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.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 reportbug depends on:
ii  apt1.8.2
ii  python33.7.3-1
ii  python3-reportbug  7.5.2
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.92-8
ii  file   1:5.35-4
ii  gnupg  2.2.12-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.2
ii  file   1:5.35-4
ii  python33.7.3-1
ii  python3-apt1.8.4
ii  python3-debian 0.1.35
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1

python3-reportbug suggests no packages.

-- no debconf information

Bug#931413: fetch-ldap-cert renews Debian Edu PKI on clients on every reboot

[Mike Gabriel]

Hi Holger,

On  Fr 05 Jul 2019 00:17:41 CEST, Holger Levsen wrote:


control: severity -1 normal
thanks

there's a workaround provided and not any justification given how this
is not a normal bug, let alone a serious one, so downgrading.


no, theres is no working around except manually patching fetch-ldap-cert.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpW1ltFjnAht.pgp
Description: Digitale PGP-Signatur

Bug#931437: installation-reports: Failure to start GUI

[Alexandros Prekates]

Package: installation-reports
Severity: normal

I used the installer with the firmware included
firmware-buster-DI-rc2-amd64-DVD-1.iso

The installation succeded , but when i booted it for
first time i was droped to command line login.

(When i installed Debian 9 in the same system 2years ago
 didnt have that issue)

My GPU is : Radeon HD 5750.

I had to search it for an hour and the package
that was needed is: firmware-linux-nonfree , firmware-amd-graphics .



-- Package-specific info:

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware
Date: 

Machine: Custom Desktop , i7-4790 , Radeon HD5750
Partitions: 


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

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

Comments/Problems:




-- 

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

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

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190623"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux enous 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core 
Processor DRAM Controller [8086:0c00] (rev 06)
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 9 Series Chipset 
Family USB xHCI Controller [8086:8cb1]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5007]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 9 Series 
Chipset Family ME Interface #1 [8086:8cba]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:1c3a]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 9 Series Chipset 
Family USB EHCI Controller #2 [8086:8cad]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5006]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 9 Series Chipset 
Family USB EHCI Controller #1 [8086:8ca6]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5006]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 9 Series Chipset 
Family H97 Controller [8086:8cc6]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 9 Series Chipset 
Family SATA Controller [AHCI Mode] [8086:8c82]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:b005]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 9 Series Chipset Family 
SMBus Controller [8086:8ca2]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
lspci -knn: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, 
Inc. [AMD/ATI] Juniper PRO [Radeon HD 5750] [1002:68be]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:21e9]
lspci -knn: 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Juniper HDMI Audio [Radeon HD 5700 Series] [1002:aa58]
lspci -knn: Subsystem: Gigabyte Technology Co., Ltd Device [1458:aa58]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-amd64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: EHCI Host Controller [8087:8009]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  

Bug#244506: info: menu lacks icon

[Norbert Preining]

Hi Hilmar,

thanks for your work.

On Thu, 04 Jul 2019, Hilmar Preuße wrote:
> May I commit the changes?

COuld you push them for now to a different branch so that I can take a
look at them, please?

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#931413: fetch-ldap-cert renews Debian Edu PKI on clients on every reboot

[Holger Levsen]

control: severity -1 normal
thanks

there's a workaround provided and not any justification given how this
is not a normal bug, let alone a serious one, so downgrading.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931436: debian-installer: RC2 Buster Installer with firmware included wont start GUI with Radeon HD 5750

[Alexandros Prekates]

Package: debian-installer
Severity: normal

Dear Maintainer,

I used the installer with the firmware included
firmware-buster-DI-rc2-amd64-DVD-1.iso

The installation succeded , but when i booted it for
first time i was droped to command line login.

(When i installed Debian 9 in the same system 2years ago
 didnt have that issue)

My GPU is : Radeon HD 5750.

I had to search it for an hour and the package
that was needed is: firmware-linux-nonfree , firmware-amd-graphics .




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.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

Bug#931435: RM: launchy -- RoQA; dead upstream, depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove launchy, it's dead upstream, orphaned since 2016
without a new maintainer and depends on the deprecated Qt4.

Cheers,
Moritz

Bug#860006: ITP: python3-aiomysql -- MySQL driver for asyncio

[Adam Cécile]

retitle 860006 ITP: python3-aiomysql -- MySQL driver for asyncio
tag 860006 + pending
owner 860006 acec...@le-vert.net
thanks

Hi,


Packages is available at debian mentors:

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/aiomysql/aiomysql_0.0.20-1.dsc


Waiting for python3-sphinxcontrib-asyncio to get accepted from NEW before doing 
further work.


Regards

Bug#931434: RM: viva -- ROM; abandoned upstream, depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Upstream development has stopped, it depends on Qt4 and upstream
recommends to remove it, but that seems to have stalled in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875226#17 ,
so filing the bug instead now.

Cheers,
Moritz

Bug#748962: texlive-bastexlive-base: fmtutil-sys --all may not return error exit code under low free space condition.

[Hilmar Preuße]

On 30.05.14 05:28, Norbert Preining wrote:

Hi Norbert,

>> If you want to contribute to the perl code, I can arrange.
> 

> Actually, due to your input I finally kicked myself to start
> this project in perl  Of course perl, because we need it running
> on all possible distributions including windows 
> (I am speaking now as TeX Live maintainer, not Debian!)
> If you want to contribute to the perl code, I can arrange.

> https://gitorious.org/tex-live-rewrites/fmtutil/
> 
Just curious: what is the status here? The repo does not exist any more.
Seems to be migrated to perl since 2017 = Debian 9. I also noticed some
code, which returns exit code > 0 in case of failure.

Can we close?

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



signature.asc
Description: OpenPGP digital signature

Bug#930487: lintian: speed up test suite CI

[Chris Lamb]

Hi Felix,

> > I'm very much in favour of us exhausting all caching opportunies, both
> > on our CI system and locally,
> 
> Would it help to separate the build product for each test package,
> which will presumably be cached, from the test output (tags.actual,
> tagdiff and friends)?

Let's zoom out here so we are not asking "Xy questions" of each other.

I think the most common use-case is that I make some change — possibly
extremely minor — in, say, checks/foo.pm and I want to re-run the
testsuite to check that I've fixed whatever false-positive or edge-case
in a tag that I am in the process of implementing. We should optimise
for kind of pattern. What do you think?

What this means in terms of the implementation detail of the testsuite
(which I'm afraid I have let get beyond my insight) I would have to
leave up to you, alas.


Regards,

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

Bug#769706: helllo

[Registraduria El Charco - Nariño]

Good day to you sir, My boss said that you should contact him via this email( 
tio...@gmail.com ) that he has some important to discuss with you.

?

?



Confidencialidad: La información contenida en este mensaje de e-mail y sus 
anexos, es confidencial y está reservada para el destinatario únicamente. Si 
usted no es el destinatario o un empleado o agente responsable de enviar este 
mensaje al destinatario final, se le notifica que no está autorizado para 
revisar, retransmitir, imprimir, copiar, usar o distribuir este e-mail o sus 
anexos. Si usted ha recibido este e-mail por error, por favor comuníquelo 
inmediatamente vía e-mail al remitente y tenga la amabilidad de borrarlo de su 
computadora o cualquier otro banco de datos. Muchas gracias.

Confidentiality Notice: The information contained in this email message, 
including any attachment, is confidential and is intended only for the person 
or entity to which it is addressed. If you are neither the intended recipient 
nor the employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that you may not review, 
retransmit, convert to hard copy, copy, use or distribute this email message or 
any attachments to it. If you have received this email in error, please contact 
the sender immediately and delete this message from any computer or other data 
bank. Thank you.

Bug#931433: unzip: CVE-2019-13232

[Salvatore Bonaccorso]

Source: unzip
Version: 6.0-23
Severity: important
Tags: security upstream
Control: found -1 6.0-21+deb9u1
Control: found -1 6.0-21

Hi,

The following vulnerability was published for unzip.

CVE-2019-13232[0]:
| Info-ZIP UnZip 6.0 mishandles the overlapping of files inside a ZIP
| container, leading to denial of service (resource consumption), aka a
| "better zip bomb" issue.

There seem to be a fork onf Info-Zip UnZip, trying to address this
issue, but not sure if we should follow that.

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-13232
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13232

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931368: Can't set hungarian keyboard layout with preseeded installer

[Samuel Thibault]

Hello,

Mayer Károly, le mer. 03 juil. 2019 12:04:00 +0200, a ecrit:
> How should I set the expected keyboard layout with preseeding?

> d-i keyboard-configuration/xkb-keymap select hu

This is the way documented on
https://www.debian.org/releases/stable/amd64/apbs04.html#preseed-l10n
so it's expected to be working yes :)

> I have no "/etc/default/keyboard" file where it should be set
> because the installer isn't installed the "console-setup" and the
> "keyboard-configuration" packages.
> Is it a bug?

That part is a bug, yes. There is no reason for console-setup not to be
installed, that's what needs to be debugged. Since you didn't use the
normal way to report an installation issue, your report includes only
very little information. Please at least provide:

- Your full preseed file.
- The installer syslog, as found in /var/log/installer/syslog

Samuel

Bug#931387: e2scrub invoked for non-LVM device

[Theodore Ts'o]

On Thu, Jul 04, 2019 at 08:52:02PM +0200, Marc Haber wrote:
> 
> I agree with you there. A few word of explanation in some readme or in
> the mail sent out by /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_fail)
> would have been nice though.

I'll at adding some comments in the scripts.

> > Reported-by: Marc Haber 
> 
> Please don't use the unplussed mail address that I have never
> communicated. mh+debian-b...@zugschlus.de would be enough, it's a valid
> and working address, and one that spammers don't handle too well.

I've ammended the commit, thanks.

- Ted

Bug#930487: lintian: speed up test suite CI

[Felix Lechner]

Hi Chris,

On Thu, Jul 4, 2019 at 12:31 PM Chris Lamb  wrote:
>
> I'm very much in favour of us exhausting all caching opportunies, both
> on our CI system and locally,

Would it help to separate the build product for each test package,
which will presumably be cached, from the test output (tags.actual,
tagdiff and friends)?

Kind regards
Felix

Bug#930487: lintian: speed up test suite CI

[Chris Lamb]

Hi Dmitry,

> What is Lintian policy on usage of languages other then Perl?

I'm very much in favour of us exhausting all caching opportunies, both
on our CI system and locally, before we introduce another language and
all the complications that would entail.


Regards,

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

Bug#930782: tomb: Invalid default cipher "aes-xts-plain64:sha256"

[S. G.]

Control: severity -1 important

I believe this bugs deserves a higher severity as the software doesn't
work relying on its defaults, at least when one creates a new tomb.

Bug#931428: release-notes: Mention FDE security issue when installing with Calamares (CVE-2019-13179)

[Justin B Rye]

Bug 931428, amending "issues":

(Can we call this package-specific for calamares?)

jonathan wrote:
> When installing Debian from live media using the Calamares installer

(add a link to the what's-new entry)

> and selecting the full disk encryption feature, the disk's unlock key
> is stored in the initramfs which is world readable. This allows users
> with local filesystem access to gain access to the private key and
> gain access to the filesystem again in the future.

Can we take out one of these repeats of "access"?  Make it "to read
the private key and"...

> This can be worked around by adding "UMASK=0077" to
> /etc/initramfs-tools/conf.d/initramfs-permissions and running
> "update-initramfs -u". This will recreate the initramfs without
> world-readable permissions.
> 
> A fix for the installer is being planned and will be uploaded to
> debian-security. In the meantime users of full disk encryption should
> apply the above workaround.
> 
> Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931373
> CVE: https://security-tracker.debian.org/tracker/CVE-2019-13179

I'm still a bit unclear about how the fix for this is going to
propagate - if it's an issue that people delaying their dist-upgrade
until next year won't need to know about then perhaps the text should
say something that won't go stale as quickly.  But for now here's a
patch.


Bug 931429, amending "whats-new":

jonathan wrote:
> Debian live images now ship an additional installer called
> Calamares. Calamares is a distribution agnostic project that aims to
> create a univeral installer. Calamare is an easy to use graphical
 ^ ^
"Universal" and presumably "Calamares", but it's clumsy to repeat
"Calamares" (and "installer") like this, especially with two different
definitions!  Could we say

 Calamares is a distribution-agnostic project that aims to
  create a universal installer, providing an easy-to-use graphical
  interface designed for typical laptop and desktop users. It doesn't
  yet support advanced partitioning options like RAID, but for advanced
  users, debian-installer is still available from the installation media
  boot menu.


And meanwhile in issues.dbk I see some text about evolution has crept
in without me noticing, so here's an extra diff for that too.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index d5fcaa36..02ab0451 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -677,5 +677,18 @@ Among many others, this release also includes the following software updates:
   
 
 
+
+  
+  Calamares installer
+  
+   Debian live images now ship an additional installer called Calamares.
+   Calamares is a distribution-agnostic project that aims to create a
+   universal installer, providing an easy-to-use graphical interface
+   designed for typical laptop and desktop users. It doesn't yet support
+   advanced partitioning options like RAID, but for advanced users,
+   debian-installer is still available from the installation media boot menu.
+  
+
+
 
 
diff --git a/en/issues.dbk b/en/issues.dbk
index b5c1d004..8cc72d44 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -692,6 +692,33 @@ $ sudo update-initramfs -u
 
   
 
+  
+
+
+  Calamares installer leaves disk encryption keys readable
+
+
+  When installing Debian from live media using the Calamares installer
+  (new in buster)
+  and selecting the full disk encryption feature, the disk's unlock key
+  is stored in the initramfs which is world readable. This allows users
+  with local filesystem access to read the private key and gain access
+  to the filesystem again in the future.
+
+
+  This can be worked around by adding UMASK=0077 to
+  /etc/initramfs-tools/conf.d/initramfs-permissions
+  and running update-initramfs -u. This will recreate
+  the initramfs without world-readable permissions.
+
+
+  A fix for the installer is being planned (see bug #931373) and will be uploaded to
+  debian-security. In the meantime users of full disk encryption should
+  apply the above workaround.
+
+  
+
 
 
 
diff --git a/en/issues.dbk b/en/issues.dbk
index b5c1d004..720bdfc0 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -684,9 +684,9 @@ $ sudo update-initramfs -u
   Users using evolution as their
   email client and connecting to a server running Exchange, Office365 or
   Outlook using the evolution-ews
-  plugin should not upgrade to Buster without backing up data and finding an
+  plugin should not upgrade to buster without backing up data and finding an
   alternative solution beforehand, as evolution-ews has been dropped due to
-  bug (#926712) and their email
+  bug #926712 and their email
   inboxes, calendar, contact lists and tasks will be re

Bug#931432: sssd: CVE-2018-16838

[Salvatore Bonaccorso]

Source: sssd
Version: 1.16.3-3.1
Severity: grave
Tags: security upstream
Forwarded: https://pagure.io/SSSD/sssd/issue/3867
Control: found -1 1.15.0-3

Hi,

The following vulnerability was published for sssd.

CVE-2018-16838[0]:
| A flaw was found in sssd Group Policy Objects implementation. When the
| GPO is not readable by SSSD due to a too strict permission settings on
| the server side, SSSD will allow all authenticated users to login
| instead of denying access.


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-2018-16838
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16838
[1] https://pagure.io/SSSD/sssd/issue/3867
[2] https://pagure.io/SSSD/sssd/c/ad058011b6b75b15c674be46a3ae9b3cc5228175

Regards,
Salvatore

Bug#931431: ITP: fanshim-python -- Python library for the Fan SHIM for Raspberry Pi

[Daniel Baumann]

Package: wnpp

  * Package name : fanshim-python
  * Upstream Author : Philip Howard
  * License : MIT
  * Homepage : https://github.com/pimoroni/fanshim-python

Regards,
Daniel

Bug#861997: ITA: flightcrew -- C++ epub validator

[François Mazen]

retitle 861997 ITA: flightcrew -- C++ epub validator
owner 861997 Francois Mazen 
thanks

I volunteer to adopt this package.
The Sigil's code seems to be the new upstream reference:
https://github.com/Sigil-Ebook/flightcrew
Best Regards,
François

Bug#931430: Acknowledgement (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[userm57]

Correction: The CPU of the Wallstreet is 266 MHz, not 292 MHz.

On 7/4/19 1:00 PM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 931430: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931430.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian X Strike Force 
> 
> If you wish to submit further information on this problem, please
> send it to 931...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#931430: X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet

[userm57]

Package: xorg-server
Version: 1.20

After installing Debian sid on a PowerBook G3 Wallstreet
(292 MHz, 512 MB memory) and selecting the default Debian
desktop and Xfce, I noticed that the desktop is unusably
slow.  Just moving or resizing windows on the desktop is
painfully slow compared to Debian 7.8 (which is usable) and
Debian 8.11 (which is still usable but slower than 7.8).

It is difficult to quantify the subjective slowness of
the graphics performance in Debian sid on the Wallstreet.
In an attempt to quantify the slowness, X11 performance
was tested and compared in Debian 7.8, Debian 8.11 and
Debian sid using the x11perf program.

Each x11perf test was run by booting to single-user mode.

For each test (Debian 7.8, Debian 8.11 and Debian sid),
there are four files:

1) Serial console log.
2) dmesg output.
3) Xorg log from /var/log/Xorg.0.log.
4) "x11perf -all" output.

There is also a file x11perfcomp.txt that compares the
three x11perf outputs.

All of the above can be found in the attachment, all.tar.xz.

Also, while determining how to run the tests, I noted that
there has been considerable growth in memory requirements
for the X server going from Debian 7.8 to Debian sid.
Here are the maximum VSZ and RSS values for the X server
as reported by "ps aux" during earlier x11perf tests (ps
was not run during any of the x11perf tests in the
attachment so it would not affect any of the results).

Debian 7.8:   X : VSZ=48MB   RSS=32MB
Debian 8.11:  X : VSZ=74MB   RSS=37MB
Debian sid:   X : VSZ=186MB  RSS=96MB

It is likely that the memory growth is a separate issue,
and it's noted here only for completeness.

Thanks go to Finn Thain, who is cc'ed on this bug report,
for his invaluable input regarding these tests.

Here is the output from x11perfcomp (also included in the
attachment).  Note that many of the micro-benchmarks show
relatively serious regressions going from 8.11 to sid.
I'm not sure which of these tests may be related to poor
desktop performance.

-

1: x11perf_7-4.20.8.txt
2: x11perf_8-4.19.56-debian-pmac.txt
3: x11perf_sid-4.19.0-5-powerpc.txt

 1 2 3Operation
      -
351.0  421.0  350.0  Dot
138.0  781000.0  885000.0  1x1 rectangle
432000.0   52700.0   63200.0  10x10 rectangle
 21400.0 612.0 658.0  100x100 rectangle
  1280.0  31.1  26.4  500x500 rectangle
137.0  361000.0  416000.0  1x1 stippled rectangle (8x8 stipple)
431000.0   35800.0   19000.0  10x10 stippled rectangle (8x8 stipple)
 21400.0 487.0 210.0  100x100 stippled rectangle (8x8 stipple)
  1280.0  16.1   8.5  500x500 stippled rectangle (8x8 stipple)
137.0  374000.0  514000.0  1x1 opaque stippled rectangle (8x8 stipple)
34.0   41600.0   57000.0  10x10 opaque stippled rectangle (8x8 stipple)
  6200.0 524.0 645.0  100x100 opaque stippled rectangle (8x8
stipple)
   262.0  17.2  25.9  500x500 opaque stippled rectangle (8x8
stipple)
137.0  467000.0  573000.0  1x1 tiled rectangle (4x4 tile)
339000.0   28300.0   33600.0  10x10 tiled rectangle (4x4 tile)
  6200.0 476.0 615.0  100x100 tiled rectangle (4x4 tile)
   262.0  15.8  26.4  500x500 tiled rectangle (4x4 tile)
328000.0  362000.0  47.0  1x1 stippled rectangle (17x15 stipple)
124000.0   46300.0   35100.0  10x10 stippled rectangle (17x15 stipple)
  3330.0 550.0 416.0  100x100 stippled rectangle (17x15 stipple)
   141.0  17.6  16.8  500x500 stippled rectangle (17x15 stipple)
304000.0  374000.0  514000.0  1x1 opaque stippled rectangle (17x15 stipple)
103000.0   44700.0   58800.0  10x10 opaque stippled rectangle (17x15
stipple)
  2700.0 574.0 654.0  100x100 opaque stippled rectangle (17x15
stipple)
   114.0  28.8  26.2  500x500 opaque stippled rectangle (17x15
stipple)
304000.0  467000.0  573000.0  1x1 tiled rectangle (17x15 tile)
103000.0   44900.0   49900.0  10x10 tiled rectangle (17x15 tile)
  2700.0 572.0 638.0  100x100 tiled rectangle (17x15 tile)
   114.0  28.7  26.3  500x500 tiled rectangle (17x15 tile)
744000.0  361000.0  454000.0  1x1 stippled rectangle (161x145 stipple)
174000.0   53100.0   36700.0  10x10 stippled rectangle (161x145 stipple)
  7230.0 626.0 419.0  100x100 stippled rectangle (161x145 stipple)
   369.0  32.3  17.0  500x500 stippled rectangle (161x145 stipple)
744000.0  373000.0  511000.0  1x1 opaque stippled rectangle (161x145
stipple)
174000.0   47400.0   6.0  10x10 opaque stippled rectangle (161x145
stipple)
  5360.0 596.0 658.0  100x100 opaque stippled rectangle (161x145
stipple)
   258.0  30.0  26.3  500x500 opaque stippled rectangle (161x145
stipple)
546000.0  451000.0  561000.0  1x1 tiled rectangle (161x145 tile)
 60800.0   44400.0   58500.0  10x10 tiled rectangle (161x145 tile)
   662.0 573.0 656.0  100x100 tiled rectangle (161x145 tile)
26.5  28.8  26.3  500x500 tiled rectangle (161x145 tile)
546000

Bug#931387: e2scrub invoked for non-LVM device

[Marc Haber]

On Thu, Jul 04, 2019 at 12:00:10PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 03, 2019 at 07:59:11PM +0200, Marc Haber wrote:
> > I don't think that having an e2 file system on a LUKS device on an LVM
> > logical volume is such an exotic thing to have.
> 
> It's not exotic, but it's not something we had tested.  So thanks for
> your bug report!  On my system I have the LVM PV on top of the LUKS
> device (so that all of the LV's are encrypted), and on your system you
> have it the other way around.

Yes, Debian does it like LV-on-PV-on-LUKS, I do it the other way because
I have some LVs with very private contents that only get unlocked when
I'm actually using it, and therefore the LUKS-on-LV scheme is more
practical here.

> So the problem is that when we scan for LVM devices:
> 
> lvs -o lv_path --noheadings -S 
> "lv_active=active,lv_role=public,lv_role!=snapshot,vg_free>256"
> 
> we get /dev/fan-c/root,

Yes

> but then when we then run lsblk on that
> device, we get something like this:
> 
> NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
> sdb   8:16   0 931,5G  0 disk  
> fan-c_root  253:00 417,2G  0 lvm   
> └─root  253:28   0 417,2G  0 crypt /

Yes.

> And so when we run lsblk -o NAME,MOUNTPOINT,FSTYPE -P -n -p
> /dev/fan-c/root we get both the top-level and subdevice:
> 
> NAME="/dev/mapper/fan-c_root" MOUNTPOINT="" FSTYPE="crypto_LUKS"
> NAME="/dev/mapper/root" MOUNTPOINT="/" FSTYPE="ext4"

Yes.

> Thanks again for the bug report!

Thanks for the reaction, for the analysis, and for the fix.

> P.S.  Sorry for the complexity; we were trying to use systemd to
> handle the error reporting.  I do wonder if we would have been better
> off if we done things the more old-fashioned way, instead of trying to
> take advantage of all of systemd's "value add".  My personal opinion
> is whether or not we like systemd, it's won the war, so we might as
> well try to take advantages of it, since we're stuck with the
> disadvantages.

I agree with you there. A few word of explanation in some readme or in
the mail sent out by /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_fail)
would have been nice though.

> e2scrub_all: correctly handle the case where LUKS is stacked on an LV
> 
> We handle the case where an LVM's PV is stacked on top of a dm-crypt
> device, but not the case where it's the other way around, where a LVM
> LV contains a LUKS encrypted file system.  Fix this oversight.
> 
> Addresses-Debian-Bug: #931387
> 
> Reported-by: Marc Haber 

Please don't use the unplussed mail address that I have never
communicated. mh+debian-b...@zugschlus.de would be enough, it's a valid
and working address, and one that spammers don't handle too well.

Greetings
Marc

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

Bug#930487: lintian: speed up test suite CI

[Felix Lechner]

Hi Dmitry,

On Thu, Jul 4, 2019 at 10:41 AM Dmitry Bogatov  wrote:
>
> It feels that build system for test suite is overconstrained now
> (rebuilds more then necessary), and I consider to make some experiments
> with Shake[1]. Should the experiments succeed, will they be accepted?

The large majority of test packages is built using
'dpkg-buildpackage'. Do you plan to rewrite it?

I looked into using golang for the test suite but, for the things we
are doing, Perl is quite fast. It's also mature and available
everywhere. How does Shake compare?

Kind regards,
Felix

Bug#931429: release-notes: document new additional installer for Debian live systems

[jonathan]

Package: release-notes
Severity: normal

Debian live images now ship an additional installer called Calamares. Calamares 
is a distribution agnostic project that aims to create a univeral installer. 
Calamare is an easy to use graphical installer designed for typical laptop and 
desktop users. It doesn't yet support advanced partitioning options like RAID, 
but for advanced users, debian-installer is still available from the 
installation media boot menu.

Bug#931428: release-notes: Mention FDE security issue when installing with Calamares (CVE-2019-13179)

[jonathan]

Package: release-notes
Severity: normal

When installing Debian from live media using the Calamares installer and 
selecting the full disk encryption feature, the disk's unlock key is stored in 
the initramfs which is world readable. This allows users with local filesystem 
access to gain access to the private key and gain access to the filesystem 
again in the future.

This can be worked around by adding "UMASK=0077" to 
/etc/initramfs-tools/conf.d/initramfs-permissions and running "update-initramfs 
-u". This will recreate the initramfs without world-readable permissions.

A fix for the installer is being planned and will be uploaded to 
debian-security. In the meantime users of full disk encryption should apply the 
above workaround.

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931373
CVE: https://security-tracker.debian.org/tracker/CVE-2019-13179

Bug#924657: kbdnames are generated with incorrect translations

[Cyril Brulebois]

Control: tag -1 patch pending

(Dropping -perl@ this time.)

Hi,

Cyril Brulebois  (2019-03-16):
> Iain Lane  (2019-03-15):
> > Package: keyboard-configuration
> > Version: 1.188
> > Severity: serious
> > Tags: patch
> > 
> > Control: forwarded -1 
> > https://salsa.debian.org/installer-team/console-setup/merge_requests/2
> > 
> > I'm reporting from my Ubuntu system but I've confirmed this also affects
> > 1.188 in buster, or any version that was built with perl ≥ 5.28.
> > 
> > The generated names in keyboard-configuration.config are translated
> > incorrectly:
> > 
> >   laney@raleigh> dpkg --ctrl-tarfile keyboard-configuration_1.188_all.deb | 
> > tar xO- ./config | grep "en_GB\*model\*sun_type6_jp"
> >   en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa)
> >   en_GB*model*sun_type6_jp_usb*Sun Type 6 USB (Japonesa)
> > 
> > That should be "(Japanese)". Very many other entries are also affected.
> > I've provided a patch on the referenced salsa URL.
> 
> Thanks for the report and the patch/MR.

The ship has sailed for buster r0 but trying to get that merged into a
later point release, I've just double-checked the effects of this patch.

By “diffing” below I mean checking the control (config script) area of
the keyboard-configuration binary package.


Diffing an unpatched package built in sid, against a patched package
built in sid: plenty of changes that look good.

Diffing an unpatched package built in stretch, against the same patched
package built in sid: fewer changes, but those can be explained by
different xkb-data versions (which is the “source” via Build-Depends,
for all those changes).

Diffing an unpatched package built in stretch but using unstable's
xkb-data, against the same patched package built in sid: no changes
at all.

So I'm quite convinced that the proposed patch makes it possible to
build the package properly, without any/other side effects that we
wouldn't have seen.


I'm therefore uploading 1.192 to unstable right now to fix this bug
there, and I'm taking a note to propose 1.192~deb10u1 through pu.

Thanks again, Iain; and apologies for the delay.


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


signature.asc
Description: PGP signature

Bug#924657: release-notes? Was: Re: kbdnames are generated with incorrect translations

[Cyril Brulebois]

Hi,

Paul Gevers  (2019-07-04):
> This apparently wasn't uploaded, so it's to late for the initial buster
> release. Does it make any sense to mention this in the release notes? I
> tend to say it doesn't, but will do it nevertheless when others think it
> does.

I see release notes as something that should be meaningful during the
the release's lifetime? I would rather see that issue documented in
installer's errata instead, as that's something we expect to be fixed
“soon”?

  
https://salsa.debian.org/webmaster-team/webwml/blob/master/english/devel/debian-installer/errata.wml

I've just double checked the effects of the patch and I'll send a
separate update, as a follow-up to the initial patch proposal.


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


signature.asc
Description: PGP signature

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

[Niko Tyni]

Control: forwarded -1 https://rt.perl.org/Public/Bug/Display.html?id=134264

On Thu, Jul 04, 2019 at 08:04:52PM +0300, Niko Tyni wrote:

> > Starting with Perl 5.28, Perl uses POSIX 2008 thread-safe locales, so
> > it calls uselocale(3) underneath when the Perl side POSIX::setlocale()
> > function is invoked.
> > 
> > This makes gettext think that a translation for the new locale is already
> > loaded when it really corresponds to the old locale.
> > 
> > While this is a 5.28 regression for Perl, it's not clear to me
> > whether glibc is working correctly here or not.

This is now reported upstream as [perl #134264].

I'm attaching an updated test case in C, which just sets LANG at startup
(as glibc won't look at LANGUAGE if the locale is totally unset / set to
"C".)

I'm also attaching a minimal Perl test case using Locale::gettext that
demonstrates the 5.26 / 5.28 difference.
-- 
Niko
#include 
#include 

#include 
#include 

/* https://bugs.debian.org/931139 */

int main(int argc, char **argv)
{
  locale_t loc;
  int i=0;

  /* The C locale is special cased in glibc to not look at LANGUAGE
 so we set C.UTF-8 as the base locale instead */
  setenv("LANG", "C.UTF-8", 1);

  char *locales[] = { "fi_FI", "fr_FR", "en_US", NULL };

  for (i=0; locales[i] != NULL; i++) {
setenv("LANGUAGE", locales[i], 1);
if (argc > 1) {
/* "Old" behaviour, no bug */
setlocale(LC_MESSAGES, "");
} else {
/* "New" behaviour, first translation stays cached */
loc = newlocale(LC_MESSAGES_MASK, "", (locale_t) 0);
if (loc == (locale_t) 0)
perror("newlocale");
uselocale(loc);
}
printf("%s\n", dgettext("bash", "syntax error"));
  }

  return EXIT_SUCCESS;
}
#!/usr/bin/perl -w
use strict;

use Locale::gettext;
use POSIX;

# The C locale is special cased in glibc to not look at LANGUAGE
# so we set C.UTF-8 as the base locale instead
$ENV{LANG} = 'C.UTF-8';

for my $lang (qw(fi_FI fr_FR en_US)) {
$ENV{LANGUAGE} = $lang;
setlocale(LC_MESSAGES, '');
my $d = Locale::gettext->domain("bash");
print $d->get('syntax error'), "\n";
}

Bug#931426: lintian: check that runscript directory has "run" script

[Dmitry Bogatov]

Package: lintian
Version: 2.15.0
Severity: wishlist

Dear Maintainer,

please add check, that if package provides runscript directory
(/etc/sv/), then /etc/sv//run is present and executable.

Usually this is handled by dh-runit, but recently I discovered bug in
dh-runit, that under some circumstances creates /etc/sv///run
instead. It would be nice to add additional safety check via Lintian.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9.1
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.13-2
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.36+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
pn  libfile-basedir-perl   
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
pn  libtext-levenshtein-perl   
pn  libtimedate-perl   
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

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

-- no debconf information


pgpUwXW1mLvex.pgp
Description: PGP signature

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Dmitry Bogatov]

[2019-07-03 02:36] Lorenz 
> Dmitry,
> sorry it took so long to send the patches,

No need to be sorry :) You are doing awesome job at tasks I do not dare
to tackle.

> but while updating the test i run into several issues i'm not able to
> solve by myself:
> * I try to include openssh into the test but it makes the test fail because
> ssh get stuck
>at boot (same issue as reported by Martin Pitt in #838480 message #49)

I confirm addition of `openssh-server' into test dependency indeed makes
it hang (my log is at bottom). I will take a look and try to reproduce
bug interactively (over VNC).

> * then i try a Vbox VM and i failed to reproduce the ssh issue, but i run
> into several other issues, see #931356

Can't we just conflict with libnss-systemd?

> Althought the test as it is now in the patches pass, we should deal
> with the above issues as they are likely hitting users that attempt
> the switch

Not sure about libnss, but I agree -- ssh server is extremely important.
Can you please file separate bug about hang boot?


autopkgtest [01:18:34]: version 5.10
autopkgtest [01:18:34]: host neophite.local; command line: /usr/bin/autopkgtest 
../runit-init_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb 
../getty-run_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb . -- qemu 
../autopkgtest.img
qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.01H:ECX.vmx [bit 5]
autopkgtest [01:18:52]: testbed dpkg architecture: amd64
autopkgtest [01:18:55]: testbed running kernel: Linux 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-5 (2019-06-19)
autopkgtest [01:18:56]:  built-tree .
autopkgtest [01:18:56]: testing package runit version 2.1.2-32
autopkgtest [01:18:56]: test init-switch: preparing testbed
Get:1 file:/tmp/autopkgtest.zHJCWY/binaries  InRelease
Ign:1 file:/tmp/autopkgtest.zHJCWY/binaries  InRelease
Get:2 file:/tmp/autopkgtest.zHJCWY/binaries  Release [816 B]
Get:2 file:/tmp/autopkgtest.zHJCWY/binaries  Release [816 B]
Get:3 file:/tmp/autopkgtest.zHJCWY/binaries  Release.gpg
Ign:3 file:/tmp/autopkgtest.zHJCWY/binaries  Release.gpg
Get:4 file:/tmp/autopkgtest.zHJCWY/binaries  Packages [3921 B]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  libedit2 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3
  libkrb5support0 libwrap0 openssh-client openssh-server openssh-sftp-server
  runit runit-helper sysuser-helper
Suggested packages:
  krb5-doc krb5-user keychain libpam-ssh monkeysphere ssh-askpass molly-guard
  rssh ufw
Recommended packages:
  krb5-locales xauth ncurses-term runit-sysv | runit-init | runit-systemd
The following NEW packages will be installed:
  libedit2 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3
  libkrb5support0 libwrap0 openssh-client openssh-server openssh-sftp-server
  runit runit-helper sysuser-helper
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 2070 kB/2194 kB of archives.
After this operation, 8259 kB of additional disk space will be used.
Get:1 file:/tmp/autopkgtest.zHJCWY/binaries  runit 2.1.2-32 [124 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 runit-helper all 2.8.6 
[4900 B]
Get:3 http://deb.debian.org/debian unstable/main amd64 sysuser-helper all 1.3.3 
[3844 B]
Get:4 http://deb.debian.org/debian unstable/main amd64 libedit2 amd64 
3.1-20181209-1 [94.0 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 libkeyutils1 amd64 1.6-6 
[15.0 kB]
Get:6 http://deb.debian.org/debian unstable/main amd64 libkrb5support0 amd64 
1.17-3 [65.6 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 libk5crypto3 amd64 
1.17-3 [121 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 libkrb5-3 amd64 1.17-3 
[370 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 libgssapi-krb5-2 amd64 
1.17-3 [158 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 openssh-client amd64 
1:7.9p1-10 [782 kB]
Get:11 http://deb.debian.org/debian unstable/main amd64 openssh-sftp-server 
amd64 1:7.9p1-10 [44.6 kB]
Get:12 http://deb.debian.org/debian unstable/main amd64 libwrap0 amd64 7.6.q-28 
[58.7 kB]
Get:13 http://deb.debian.org/debian unstable/main amd64 openssh-server amd64 
1:7.9p1-10 [352 kB]
Preconfiguring packages ...
Fetched 2070 kB in 0s (21.3 MB/s)
Selecting previously unselected package runit-helper.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(R

Bug#930487: lintian: speed up test suite CI

[Dmitry Bogatov]

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

What is Lintian policy on usage of languages other then Perl?
It feels that build system for test suite is overconstrained now
(rebuilds more then necessary), and I consider to make some experiments
with Shake[1]. Should the experiments succeed, will they be accepted?

 [1] https://shakebuild.com
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Dmitry Bogatov]

control: tags -1 +pending

[2019-07-03 01:27] Lorenzo Puliti 
> Package: runit
> Version: 2.1.2-31
> Followup-For: Bug #930758
>
> Hi,
> it looks like init-system-helpers 1.57 breaks the test (it removes runit-init 
> from
> the list of supported init).
> Anyway the following patches should work

Wonderful. Yes, it works. I slightly reformatted code and merged.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#931427: RFP: diff-so-fancy - make your diffs human readable

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist

Name: diff-so-fancy
URL: https://github.com/so-fancy/diff-so-fancy
Language: Perl
Description:

diff-so-fancy strives to make your diffs human readable instead
of machine readable. This helps improve code quality and helps
you spot defects faster.

The difference between stock git diff hightlighting and diff-so-fancy is
best shown by screenshot on project website.


pgpFEAXVoeQmF.pgp
Description: PGP signature

Bug#931425: dh-runit: creates /etc/sv/foo/foo

[Dmitry Bogatov]

Package: dh-runit
Version: 2.8.12
Severity: important

Dear Maintainer,

following content of .runit file (took from djbdns package)

debian/service/djbdns disable,logscript

where debian/service/djbdns is directory causes creation of malformed
runscript:

/etc/sv/dnscache/dnscache/run
/etc/sv/dnscache/dnscache/...

Interestingly, 2.8.8 seems to work fine.

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


pgpa7q1BEiMDS.pgp
Description: PGP signature

Bug#931424: openjdk-13 should stay in unstable for now

[Matthias Klose]

Source: openjdk-13
Version: 13~28-1
Severity: serious

openjdk-13 should stay in unstable for now, it is another short lived version
leading to the next LTS release. However we need these versions to ease updating
our packages.

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

[Niko Tyni]

On Thu, Jun 27, 2019 at 12:08:53AM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.28.1-6
> Severity: important
> 
> As discussed in #924657, glibc has a cache of already loaded translations
> that gets invalidated (by incrementing _nl_msg_cat_cntr) in setlocale(3),
> bindtextdomain(3) and textdomain(3) but not uselocale(3).
> 
> Starting with Perl 5.28, Perl uses POSIX 2008 thread-safe locales, so
> it calls uselocale(3) underneath when the Perl side POSIX::setlocale()
> function is invoked.
> 
> This makes gettext think that a translation for the new locale is already
> loaded when it really corresponds to the old locale.
> 
> While this is a 5.28 regression for Perl, it's not clear to me
> whether glibc is working correctly here or not.

Attached is a C test program demonstrating the behaviour.

When called without arguments, it uses uselocale(3) so the first
translation gets used for all the languages. This is the "buggy" behaviour.

When called with any arguments, it uses setlocale(3) and works as
intended, outputting the string in three different languages.

The issue is only visible when using the LANGUAGE environment variable
to select the translation. Setting LC_MESSAGES, LANG or LC_ALL hides
the issue. This is because LC_*/LANG affect the locale value that is
used to compute the cache hashing key inside glibc (in DCIGETTEXT(),
a.k.a. __dcigettext() ) while LANGUAGE doesn't.

  https://sources.debian.org/src/glibc/2.28-10/intl/dcigettext.c/#L543

As noted above, the primary difference between using setlocale(3)
and uselocale(3) here is that the former invalidates the cache while
the latter does not.

The difference between Perl 5.26 and 5.28 is that when calling
&POSIX::setlocale(), the former uses setlocale(3) while the latter
uses uselocale(3).
-- 
Niko Tyni   nt...@debian.org
#include 
#include 

#include 
#include 

/* https://bugs.debian.org/931139 */

int main(int argc, char **argv)
{
  locale_t loc;
  int i=0;

  char *locales[] = { "fi_FI", "fr_FR", "en_US", NULL };

  for (i=0; locales[i] != NULL; i++) {
setenv("LANGUAGE", locales[i], 1);
if (argc > 1) {
/* "Old" behaviour, no bug */
setlocale(LC_MESSAGES, "");
} else {
/* "New" behaviour, first translation stays cached */
loc = newlocale(LC_MESSAGES_MASK, "", (locale_t) 0);
if (loc == (locale_t) 0)
perror("newlocale");
uselocale(loc);
}
printf("%s\n", dgettext("bash", "syntax error"));
  }

  return EXIT_SUCCESS;
}

Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk

[Mark Caglienzi]

Hi all,
is this bug relevant yet?

I have a buster laptop (so no VM, but real hardware, and no fresh
install) with encrypted disk, and I blocked the upgrade of grub since
March because of the fear to not be able to boot it after the upgrade of
grub.

I am still with 2.02+dfsg1-12 because of this.

The severity is critical (and if the bug is confirmed, I understand
that's *critical*), but I don't understand if I can upgrade or not.

I don't see "movement" in the thread since some months, and the bug just
"lies here".

Thanks in advance,
Mark



signature.asc
Description: OpenPGP digital signature

Bug#931389: LXQt: SDDM does not start

[Steve McIntyre]

Hi Kevin,

Thanks for giving us feedback.

On Wed, Jul 03, 2019 at 07:11:15PM +, Kevin Williams wrote:
>Package: installation-reports
>
>Boot method: ISO image
>Image version: 
>https://cdimage.debian.org/cdimage/buster_di_rc3/amd64/iso-cd/debian-buster-DI-rc3-amd64-netinst.iso
>Date: 2019-07-03 1200 CDT
>
>Machine: Hyper-V on Win10 1903
>Processor: Intel Core i7-3770
>Memory: 2 GB
>Partitions:
>
>udev   devtmpfs968968  0   968968  0%  /dev
>tmpfs  tmpfs   197744  3268194476  2%  /run
>/dev/sda1  ext449278612 42605344   9%  /
>tmpfs  tmpfs   988708  7788980920  1%  /dev/shm
>tmpfs  tmpfs   51200   51200%  /run/lock
>tmpfs  tmpfs   988708  0   988708  0%  /sys/fs/cgroup
>tmpfs  tmpfs   197740  8   197732  1%  /run/user/1000
...

>Comments/Problems:
>
>If I tell tasksel to install the desktop environment + LXQt, sddm will 
>not start, but startx will bring up the GUI.  If I instead have it 
>install MATE or LXDE, a GUI login screen comes up.
>
>I have not tried other DEs yet.

That's odd. I've just done a test installation of lxqt here in
qemu/kvm using that image and I can't reproduce your problem - see

  https://www.einval.com/~steve/tmp/lxqt-rc3.png

from straight after boot. Could you give us a copy of your
installation syslog please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Bug#931387: e2scrub invoked for non-LVM device

[Theodore Ts'o]

Control: tags -1 +pending

On Wed, Jul 03, 2019 at 07:59:11PM +0200, Marc Haber wrote:
> 
> (additional issue #1)
> the -C option is not mentioned in the e2scrub_all manual page,

That's been fixed (by removing the -C) upstream already.

commit 6ec2060a291b873ba120aa7cda940c6604eac550
Author: Darrick J. Wong 
Date:   Mon Jun 3 21:27:12 2019 -0700

e2scrub: remove -C from e2scrub_all

We already have the "SERVICE_MODE=1" feature that signals to e2scrub
that we're running as a background daemon and therefore we should exit
quietly if conditions aren't right.

It's therefore unnecessary to have a separate -C flag to achieve the
same outcome for cron jobs.  Merge the two together.

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

> (additional issue #2)
> e2scub_all -n reveals that it would actually invoke systemctl start
> e2scrub@- which, manually invoked, gives some feedback about its
> failure:

Yes, that was a bug; e2scprobe e2scrub_all should haven't issued the
"systemctl start e2scrub@-" command for your system.

> I don't think that having an e2 file system on a LUKS device on an LVM
> logical volume is such an exotic thing to have.

It's not exotic, but it's not something we had tested.  So thanks for
your bug report!  On my system I have the LVM PV on top of the LUKS
device (so that all of the LV's are encrypted), and on your system you
have it the other way around.

So the problem is that when we scan for LVM devices:

lvs -o lv_path --noheadings -S 
"lv_active=active,lv_role=public,lv_role!=snapshot,vg_free>256"

we get /dev/fan-c/root, but then when we then run lsblk on that
device, we get something like this:

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb   8:16   0 931,5G  0 disk  
fan-c_root  253:00 417,2G  0 lvm   
└─root  253:28   0 417,2G  0 crypt /

And so when we run lsblk -o NAME,MOUNTPOINT,FSTYPE -P -n -p
/dev/fan-c/root we get both the top-level and subdevice:

NAME="/dev/mapper/fan-c_root" MOUNTPOINT="" FSTYPE="crypto_LUKS"
NAME="/dev/mapper/root" MOUNTPOINT="/" FSTYPE="ext4"

That was the root cause of the failure.  Attached please find the fix
that I have applied to my git repo, and which will be in the next
release of e2fsprogs.

Thanks again for the bug report!

- Ted

P.S.  Sorry for the complexity; we were trying to use systemd to
handle the error reporting.  I do wonder if we would have been better
off if we done things the more old-fashioned way, instead of trying to
take advantage of all of systemd's "value add".  My personal opinion
is whether or not we like systemd, it's won the war, so we might as
well try to take advantages of it, since we're stuck with the
disadvantages.  And to be fair to systemd, the problems we've been
having haven't been with e2scrube_all triggering e2scrub@ and
with the service file triggering e2scrub_fail@ if there we need
to send a report to the system administrator.  The fact that we have
to use systemd-escape to transmogrify "/" to "-", and "/usr/projects"
to "-usr-projects" is certainly confusing (which is where e2scrub@-
comes from) --- but it hasn't been the actual cause of the e2scrub
bugs that we've had.

The bugs that we have found have been more in the complex stacking of
dm-crypt, luks, etc, and our trying to use "lvs" and "lsblk" to figure
out which devices should get scrubbed.  And there have been a bunch
hiding there --- and we currently don't scrub file systems on
thin-provisioned (dm-thinkp) devices at all, because that would be
even harder to get right.  So the issues have been on the
lvm/thinp/lsblk side, not the systemd integration aspect.


 commit 0207f41174ac94eb98ed29e52bc6e1c5f6a8bdd3
Author: Theodore Ts'o 
Date:   Thu Jul 4 11:39:45 2019 -0400

e2scrub_all: correctly handle the case where LUKS is stacked on an LV

We handle the case where an LVM's PV is stacked on top of a dm-crypt
device, but not the case where it's the other way around, where a LVM
LV contains a LUKS encrypted file system.  Fix this oversight.

Addresses-Debian-Bug: #931387

Reported-by: Marc Haber 
Signed-off-by: Theodore Ts'o 

diff --git a/scrub/e2scrub_all.in b/scrub/e2scrub_all.in
index cdc37ced..24b2c681 100644
--- a/scrub/e2scrub_all.in
+++ b/scrub/e2scrub_all.in
@@ -102,8 +102,9 @@ ls_scan_targets() {
 if [ -z "$devices" ]; then
return 0;
 fi
-lsblk -o NAME,MOUNTPOINT,FSTYPE -P -n -p $devices | \
-   grep FSTYPE=\"ext\[234\]\" | while read vars ; do
+lsblk -o NAME,MOUNTPOINT,FSTYPE,TYPE -P -n -p $devices | \
+   grep FSTYPE=\"ext\[234\]\" | grep TYPE=\"lvm\" | \
+   while read vars ; do
eval "${vars}"
 
if [ "${scrub_all}" -eq 1 ] || [ -n "${MOUNTPOINT}" ]; then

Bug#572226: tex4ht: Incorrect output for align, eqnarray, inline longrightarrow

[Hilmar Preuße]

On 02.03.10 15:17, Sebastian Canagaratna wrote:

Hi Sebastian,

sorry, late response.

> tex4ht does not render amsmath align environment correctly: it appears
> to form two png's one for the LHS and one for the RHS; the = sign is not
> included in the png and the rendering is misaligned.
> 
> With Latex's eqnarray, the alignment is fine, since only one png is
> formed, but the eqn number is not flush with the right margin
> 
> When \longrightarrow is used inline it is rendered by a small dash
> followed by a small arrow; in display style math, it is rendered OK.
> 
Could you provide a minimal file example for this issue?

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



signature.asc
Description: OpenPGP digital signature

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Vincent Lefevre]

On 2019-07-04 16:57:22 +0300, Niko Tyni wrote:
> and the following passage in perlop:
> 
> Unary "-" performs arithmetic negation if the operand is numeric,
> including any string that looks like a number. If the operand is an
> identifier, a string consisting of a minus sign concatenated with
> the identifier is returned.
> 
> So it looks like this is intentional or at least documented
> behaviour that we're stuck with.

No, that's just the default behavior, without strict subs.
Similarly, the perlop(1) man page says:

  Unary "+" has no effect whatsoever, even on strings. [...]

Thus:

zira:~> perl -e 'my $x = -Inf; print "$x\n";'
-Inf
zira:~> perl -e 'my $x = +Inf; print "$x\n";'
Inf

as documented. But with "use strict;", the one with +Inf gives
an error, but not the one with -Inf.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#931419: [Pkg-utopia-maintainers] Bug#931419: network-manager: Support for multiple wired networks is confusing

[Mark Brown]

On Thu, Jul 04, 2019 at 05:09:08PM +0200, Michael Biebl wrote:
> Am 04.07.19 um 16:14 schrieb Mark Brown:

> > I actually see the same behaviour with the CLI and TUI as I do
> > with the GNOME settings stuff - there's nothing obvious that
> > suggests that the two connections are mutually exclusive (in the
> > TUI they do both say "Wired Connection 1" but that's a child of
> > the interface so those configs look like they're per-interface).
> > AFAICT the exclusion is being enforced at the NM level and the
> > clients are just passing through what they see through the APIs.

> > Anyway, I'm attaching an image showing the GNOME settings app.

> So you have two network interfaces but one connection profile?
> Can you attach that connection profile (see
> /etc/NetworkManager/system-connections)?
> I still struggle to understand your problem tbh.

I don't know what a "connection profile" is, I didn't configure
one knowingly.  I just tried to click "enable" on the interfaces.
Anyway, attaching.
[connection]
id=Wired connection 1
uuid=ee6d6cf2-5f27-43d0-af17-16d67291e0cc
type=ethernet
permissions=
timestamp=1562192049

[ethernet]
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
address1=REDACTED
dns-search=
ip6-privacy=2
method=manual


signature.asc
Description: PGP signature

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

[Gianfranco Costamagna]

 ok, so three packages should be fixed:unstable (done)testing via 
proposed-updates (aka buster)stable via proposed-updates (aka stretch)
please if you care open two bugs against release.debian.org and get them 
accepted, and ping me back!
G.

Il giovedì 4 luglio 2019, 17:02:51 CEST, Takashi Kanamaru 
 ha scritto:  
 
 Dear Gianfranco,

Threre are two patches as follows:

For lirc-0.9.4c:
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir.patch

For lirc-0.10.1:
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch

Please note that the patch for lirc-0.9.4c cannot be applied to lirc-0.10.1
because "mode2.cpp" in  lirc-0.10.1 is slightly different from that of
lirc-0.9.4c.

Similarly, applying the patch for lirc-0.10.1 to lirc-0.9.4c will fail
although I have not tried it.

Sincerely,

Takashi Kanamaru
  

Bug#931419: [Pkg-utopia-maintainers] Bug#931419: network-manager: Support for multiple wired networks is confusing

[Michael Biebl]

Am 04.07.19 um 16:14 schrieb Mark Brown:
> On Thu, Jul 04, 2019 at 03:59:59PM +0200, Michael Biebl wrote:
>> Am 04.07.19 um 13:55 schrieb Mark Brown:
> 
>>> On a system with multiple wired networks Network Manager displays
>>> them separately (eg, in the system settings app I see two network
>>> connections listed with separate settings buttons and on/off
>>> toggles) but in actual fact there is only a single set of wired
>>> settings and toggling one connection on toggles other wired
>>> connections off.  Similar things happen when configuring via the
>>> system menu.
> 
>> Could you add a screenshot which highlights the problem you are seeing?
>> network-manager itself does not provide any GUI (only a CLI and TUI).
> 
> I actually see the same behaviour with the CLI and TUI as I do
> with the GNOME settings stuff - there's nothing obvious that
> suggests that the two connections are mutually exclusive (in the
> TUI they do both say "Wired Connection 1" but that's a child of
> the interface so those configs look like they're per-interface).
> AFAICT the exclusion is being enforced at the NM level and the
> clients are just passing through what they see through the APIs.
> 
> Anyway, I'm attaching an image showing the GNOME settings app.
> 

So you have two network interfaces but one connection profile?
Can you attach that connection profile (see
/etc/NetworkManager/system-connections)?
I still struggle to understand your problem tbh.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#931423: kwalletcli: How can the content of Maps entry can be read with kwalletcli ?

[Dominique Dumont]

Package: kwalletcli
Version: 3.02-1
Severity: normal
Tags: upstream

Dear Maintainer,

I've setup Maps entries using kwalletmanager. Unfortunately, I cannot
figure out how to retrieve the content of Maps using a kwalletcli.

For instace, kwalletmanager show entries like:

\/ Passwords (26)
  > Passwords
  \/ Maps
 stuff

stuff is a Name-Value Map containing foo and bar Keys.

I've tried:
$ kwalletcli -f Passwords -e stuff
[no output]
$ kwalletcli -f Passwords -e stuff/user
entry does not exists
$ kwalletcli -f Passwords/stuff -e user
folder does not exists

Is there a way to get the value of "user" Key stored in "stuff" Maps
in "Passwords folder ?

If yes, shoudln't that be documentated ?

All the best


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

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

Versions of packages kwalletcli depends on:
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5wallet-bin   5.54.0-1
ii  libkf5wallet5  5.54.0-1
ii  libqt5core5a   5.11.3+dfsg1-2
ii  libqt5widgets5 5.11.3+dfsg1-2
ii  libstdc++6 8.3.0-7
ii  mksh   57-1

Versions of packages kwalletcli recommends:
ii  gnupg-agent 2.2.13-2
ii  gpg-agent [gnupg-agent] 2.2.13-2
ii  kwalletmanager  4:18.04.1-1
ii  openssh-client  1:7.9p1-10
ii  pinentry-curses [pinentry]  1.1.0-2
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-2
ii  pinentry-qt [pinentry-x11]  1.1.0-2
ii  pinentry-qt41.1.0-2

kwalletcli suggests no packages.

-- no debconf information

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

[Takashi Kanamaru]

Dear Gianfranco,

Threre are two patches as follows:

For lirc-0.9.4c:
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir.patch

For lirc-0.10.1:
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch

Please note that the patch for lirc-0.9.4c cannot be applied to lirc-0.10.1
because "mode2.cpp" in  lirc-0.10.1 is slightly different from that of
lirc-0.9.4c.

Similarly, applying the patch for lirc-0.10.1 to lirc-0.9.4c will fail
although I have not tried it.

Sincerely,

Takashi Kanamaru

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

[Gianfranco Costamagna]

On Wed, 3 Jul 2019 21:27:22 +0900 Takashi Kanamaru  
wrote:
> Dear Gianfranco and Alec,
> 
> Thank you for accepting the patch.
> 
> If possible, please accept also the patch for lirc 0.10.1-5.2
> because the release of Debian Buster is approaching.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931078
> 
> Sincerely,
> 
> Takashi Kanamaru

Hello, I see #931078 is referring to a more complete but similar patch wrt this 
one #930485.

the only difference is this one
-#define LINE_LEN 1024
+#define LINE_LEN 4096


So, I'm going to upload that patch in unstable *now*
but since deep freeze is already past, we need to ask for an exception via
reportbug release.debian.org, asking to accept a proposed-updates upload.

Can you please do it if you care? You should also explain why it breaks, and 
convince them that no regressions are possible.

G.

Bug#767871: tex4ht: htlatex cannot find latex

[Hilmar Preuße]

On 03.11.14 07:16, Johannes Schauer wrote:

Hi Norbert, hi Josch,

> steps to reproduce:
> 
> $ apt-get install tex4ht
> $ touch test.tex
> $ htlatex test.tex
> /usr/bin/htlatex: 8: /usr/bin/htlatex: latex: not found
> /usr/bin/htlatex: 9: /usr/bin/htlatex: latex: not found
> /usr/bin/htlatex: 10: /usr/bin/htlatex: latex: not found
> 
> 
> So should the package not depend or at least recommend texlive-latex-base?
> 
Not sure how to solve this. Current situation is:

- htlatex is provided by texlive-plain-generic
- texlive-plain-generic has a dep on texlive-base & texlive-binaries

So one has a basic TeX installation but latex is not available in 100%
of all cases. I tend to add suggest: texlive-latex-base to
texlive-plain-generic.

Any opinion?

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



signature.asc
Description: OpenPGP digital signature

Bug#244506: info: menu lacks icon

[Hilmar Preuße]

On 18.04.04 20:17, Fabian Franz wrote:

Hi Norbert,

> please add a icon to your package.
> 
> You can take one from KDE or Gnome iconsets called "khelpcenter".
> Even if I would prefer a icon like a questionmark: ?
> 
I've built an "integration" for that (we would now have an icon) and
switched away from the menu system at the same time. The Icon comes from
the package gnome-icon-theme (15 MB installed size), hence we'd need to
declare a depend on it. On the other side "This package contains the
default icon theme used by the GNOME desktop.", hence I'd expect that
most of the computers do have it anyway. Maybe a recommends is OK for
people w/ small installations.

May I commit the changes?

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



signature.asc
Description: OpenPGP digital signature

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Alberto Luaces Fernández]

What is the status of the user unit?

systemctl --user status anbox-session-manager

Can you verify both kernel modules are loaded correctly?

ls /dev/{binder,ashmem}

Bug#931422: Segmentation fault opening TIFF file

[Christopher Chavez]

Package: libtk-img
Version: 
1:1.4.6+dfsg-1


Using Debian 9.9 i386 (32-bit). I am not sure if this bug should instead be 
reported against libtiff5 (4.0.8-2+deb9u4).

A segmentation fault occurs when using the following 3-line script and an 
example image obtained from 
https://sourceforge.net/p/openil/svn/1479/tree/trunk/Test%20Images/TIF/libtiffpic/quad-jpeg.tif
 . I am not aware of any other example images that exhibit the exact same issue.


package require Tk
package require Img
image create photo icon -file "libtiffpic/quad-jpeg.tif” -format tiff


Here is the result of running this in Valgrind:

$ valgrind --num-callers=100 wish8.6 img-tiff-segfault.tcl
==14493== Memcheck, a memory error detector
==14493== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14493== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==14493== Command: wish8.6 img-tiff-segfault.tcl
…
==14493== Invalid read of size 4
==14493==at 0x581659B: tagCompare (tif_dirinfo.c:349)
==14493==by 0x581659B: bsearch (stdlib-bsearch.h:33)
==14493==by 0x581659B: TIFFFindField (tif_dirinfo.c:526)
==14493==by 0x58168B1: TIFFFieldWithTag (tif_dirinfo.c:562)
==14493==by 0x5814A0C: _TIFFVSetField (tif_dir.c:709)
==14493==by 0x5815893: TIFFSetField (tif_dir.c:798)
==14493==by 0x581D78E: TIFFReadDirectory (tif_dirread.c:3623)
==14493==by 0x5841E99: TIFFClientOpen (tif_open.c:466)
==14493==by 0x57CBA8B: ChnRead (tiff.c:536)
==14493==by 0x48E2E2E: ImgPhotoConfigureMaster (tkImgPhoto.c:1947)
==14493==by 0x48E0586: ImgPhotoCreate (tkImgPhoto.c:360)
==14493==by 0x48D5F16: Tk_ImageObjCmd (tkImage.c:373)
==14493==by 0x49E8304: Dispatch (tclBasic.c:4357)
==14493==by 0x49E8357: TclNRRunCallbacks (tclBasic.c:4390)
==14493==by 0x49E776C: Tcl_EvalObjv (tclBasic.c:4120)
==14493==by 0x49E901B: TclEvalEx (tclBasic.c:5259)
==14493==by 0x4AA2F80: Tcl_FSEvalFileEx (tclIOUtil.c:1826)
==14493==by 0x4888399: Tk_MainEx (tkMain.c:342)
==14493==by 0x10880E: main (tkAppInit.c:78)
==14493==  Address 0x832f8b00 is not stack'd, malloc'd or (recently) free'd
==14493== 
==14493== 
==14493== Process terminating with default action of signal 11 (SIGSEGV)
==14493==  Access not within mapped region at address 0x832F8B00
==14493==at 0x581659B: tagCompare (tif_dirinfo.c:349)
==14493==by 0x581659B: bsearch (stdlib-bsearch.h:33)
==14493==by 0x581659B: TIFFFindField (tif_dirinfo.c:526)
==14493==by 0x58168B1: TIFFFieldWithTag (tif_dirinfo.c:562)
==14493==by 0x5814A0C: _TIFFVSetField (tif_dir.c:709)
==14493==by 0x5815893: TIFFSetField (tif_dir.c:798)
==14493==by 0x581D78E: TIFFReadDirectory (tif_dirread.c:3623)
==14493==by 0x5841E99: TIFFClientOpen (tif_open.c:466)
==14493==by 0x57CBA8B: ChnRead (tiff.c:536)
==14493==by 0x48E2E2E: ImgPhotoConfigureMaster (tkImgPhoto.c:1947)
==14493==by 0x48E0586: ImgPhotoCreate (tkImgPhoto.c:360)
==14493==by 0x48D5F16: Tk_ImageObjCmd (tkImage.c:373)
==14493==by 0x49E8304: Dispatch (tclBasic.c:4357)
==14493==by 0x49E8357: TclNRRunCallbacks (tclBasic.c:4390)
==14493==by 0x49E776C: Tcl_EvalObjv (tclBasic.c:4120)
==14493==by 0x49E901B: TclEvalEx (tclBasic.c:5259)
==14493==by 0x4AA2F80: Tcl_FSEvalFileEx (tclIOUtil.c:1826)
==14493==by 0x4888399: Tk_MainEx (tkMain.c:342)
==14493==by 0x10880E: main (tkAppInit.c:78)

Bug#909062: kdump is gone

[Gürkan Myczko]

so no need anymore for kdump.8

kexec-tools doesn't provide kdump anymore
and kdump-config only has a binary kdump-config, no kdump...

best,

Bug#931419: [Pkg-utopia-maintainers] Bug#931419: network-manager: Support for multiple wired networks is confusing

[Michael Biebl]

Am 04.07.19 um 13:55 schrieb Mark Brown:
> Package: network-manager
> Version: 1.14.6-2
> Severity: normal
> 
> On a system with multiple wired networks Network Manager displays
> them separately (eg, in the system settings app I see two network
> connections listed with separate settings buttons and on/off
> toggles) but in actual fact there is only a single set of wired
> settings and toggling one connection on toggles other wired
> connections off.  Similar things happen when configuring via the
> system menu.

Could you add a screenshot which highlights the problem you are seeing?
network-manager itself does not provide any GUI (only a CLI and TUI).

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



signature.asc
Description: OpenPGP digital signature

Bug#931421: arp-scan: Still distributing and using internal oui.txt and iab.txt files

[Nelson A. de Oliveira]

close #931421
thanks

Ah... now I see that get-iab/get-oui are actually processing the files
from ieee-data.
I am sorry for the confusion here.

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Niko Tyni]

On Thu, Jul 04, 2019 at 02:10:22PM +0200, Vincent Lefevre wrote:
> Package: perl
> Version: 5.28.1-6
> Severity: normal
> 
> The following does no yield any error:
> 
>   perl -e 'use strict; my $x = - Inf;'
> 
> This does not seem to be intended.

Inf is not special here, other strings behave similarly.

Googling a bit turns up

 
https://stackoverflow.com/questions/23215511/ambiguous-use-of-constant-resolved-as-constant

 https://www.perlmonks.org/?node_id=1047125

and the following passage in perlop:

Unary "-" performs arithmetic negation if the operand is numeric,
including any string that looks like a number. If the operand is an
identifier, a string consisting of a minus sign concatenated with
the identifier is returned.

So it looks like this is intentional or at least documented
behaviour that we're stuck with.
-- 
Niko Tyni   nt...@debian.org

Bug#931421: arp-scan: Still distributing and using internal oui.txt and iab.txt files

[Nelson A. de Oliveira]

Package: arp-scan
Version: 1.9.5-1
Severity: normal

Hi!

It seems that #481296 and #739200 aren't really fixed.

While arp-scan now depends on ieee-data, it is still including and
distributing the following files:

/usr/share/arp-scan/ieee-iab.txt
/usr/share/arp-scan/ieee-oui.txt
/usr/share/arp-scan/mac-vendor.txt

If it depends on ieee-data then there is no need to also have these
files (nor have /usr/sbin/get-iab and /usr/sbin/get-oui).

Also, arp-scan isn't using the shared files.

If we renamed the /usr/share/arp-scan/*txt files, arp-scan won't use the
shared files from /usr/share/ieee-data/:

=
# arp-scan -l
Interface: eth0, datalink type: EN10MB (Ethernet)
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-oui.txt: No such 
file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-iab.txt: No such 
file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/mac-vendor.txt: No 
such file or directory
Starting arp-scan 1.9.5 with 64 hosts (https://github.com/royhills/arp-scan)
=

Thank you!

Best regards,
Nelson

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

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

Versions of packages arp-scan depends on:
ii  ieee-data   20180805.1
ii  libc6   2.28-10
ii  libpcap0.8  1.8.1-6

Versions of packages arp-scan recommends:
ii  libwww-perl  6.36-2

arp-scan suggests no packages.

-- no debconf information

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 02:13:03PM +0200, Bas Couwenberg wrote:
> How often do you expect to need NEW processing for monit?

Probably, once every major release.  Backport is a frequent request.

> Do you know any users of the package who have contributed patches or other
> maintainer type bugreports that could be recruited to help co-maintain the
> package?

Yes, take look in the history.  Someone was added to Uploaders, but
after year+ of inactivity - I've decided to remove that contributor.

> My strong preference is for you to maintain the backport as you are the most
> able maintainer of the package, so I hope we can find a solution where I can
> support you with the unpleasant bureaucracy to enable you keep doing your
> work on the monit package (and its backports).

Ok, ping me (e.g. with a bug), when this option will be available.  I'll
provide a package after few days.

Bug#929931: [Pkg-samba-maint] Bug#929931: CTDB: Debian Enablement (focus: NFS HA)

[Rafael David Tinoco]

> Have you sent all patches to upstream? Once this is done, please
> propose a MR at:
> https://salsa.debian.org/samba-team/samba
>
> (with cherry-picked commits, with "-x")
>
> Those may go in Debian 10 buster.

I'm still waiting for some reviews on a merge request to Ubuntu Eoan.
As soon as I get that sorted out I'll propose the same merge request
to Debian (for the affected parts) and start backporting it to some
other Ubuntu versions (fyio).

Merge request: 
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/samba/+git/samba/+merge/368550

Thanks a lot!

Bug#931420: smartmontools: The d/10mail script should fallback to sendmail if mail(1) isn't available

[Paride Legovini]

Package: smartmontools
Version: 6.6-1
Severity: normal

Dear maintainers,

smartmontools relies on mail(1) to send its warning emails, and indeed
Recommends: mailx | mailutils. This however does take into account that
there are systems which are perfectly able to send mail using the
sendmail MTA, but where mail(1) is not available. smartmontools is
currently not able to send mail from these setups, and just installing a
mailx-compatible MUA is sometimes not enough without extra configuration
steps. This situation is not ideal.

This issue has been first brought up in Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/181

where Christian Franke (smartmontools upstream developer) notes that the email
sending process is handled by the 10mail script, which is part of the Debian
packaging. He suggests to modify the script so it fallbacks to sendmail if
mail(1) isn't available, e.g. like this:

=== 10mail

#!/bin/bash
mail=/usr/bin/mail
sendmail=/usr/sbin/sendmail
if [ -x $mail ]; then
  echo "$SMARTD_FULLMESSAGE" | $mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS
elif [ -x $sendmail ]; then
  $sendmail $SMARTD_ADDRESS <

Bug#918250: Facter: Could not process routing table entry: Expected a destination followed by key/value pairs

[Moritz Muehlenhoff]

severity 918250 important
thanks

On Fri, Jan 04, 2019 at 07:57:42PM +0100, Bernhard Schmidt wrote:
> Package: facter
> Version: 3.11.0-1.1
> Severity: minor
> 
> After upgrading a test-VM from Stretch to Buster the following error appears
> with every puppet run
> 
> Warning: Facter: Could not process routing table entry: Expected a 
> destination followed by key/value pairs, got 'default via fe80::1 dev ens18 
> metric 1024 onlink pref medium'
> 
> root@opsvm:~# ip -6 route
> ::1 dev lo proto kernel metric 256 pref medium
> 2001:1b10:100:3::/64 dev ens18 proto kernel metric 256 pref medium
> fe80::/64 dev ens18 proto kernel metric 256 pref medium
> default via fe80::1 dev ens18 metric 1024 onlink pref medium
> 
> This is most likely
> 
> https://tickets.puppetlabs.com/browse/FACT-1885

Hi Puppet maintainers,
after the upgrade to facter 3.11 at the Wikimedia Foundation (from the 
ruby-based 2.4.6 in Stretch)
we've run into the same on a number of servers; Puppet runs have become quite 
spammy, see below for
example output from a Puppet run on one of our Varnish cache hosts:

A colleague of mine (CCed) tracked this down to 
https://tickets.puppetlabs.com/browse/FACT-1916 and
submitted a patch which got merged to the 3.11 branch as
https://github.com/puppetlabs/facter/commit/0e089f585362fa508caed5af598d615d0da24d05

The patch is self-contained and seems like a sensible candidate for a Buster 
point update once fixed
in unstable? If you agree, I'd be happy to do the legwork of preparing a Buster 
update and proposing
an update to the stable release team.

Cheers,
Moritz


% sudo puppet agent -t  
   [10:23:31]
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.0.130 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.0.132 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.16.22 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.16.24 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.32.67 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.32.69 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.48.101 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.64.48.103 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.0.122 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.0.125 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.0.127 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.16.133 via 10.20.0.1 dev eno1  mtu 
lock 1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.16.136 via 10.20.0.1 dev eno1  mtu 
lock 1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.16.138 via 10.20.0.1 dev eno1  mtu 
lock 1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.32.112 via 10.20.0.1 dev eno1  mtu 
lock 1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.32.115 via 10.20.0.1 dev eno1  mtu 
lock 1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.48.23 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '10.192.48.27 via 10.20.0.1 dev eno1  mtu lock 
1450'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed by key/value pairs, got '2620:0:860:101:10:192:0:122 via fe80::1 dev 
eno1 metric 1024  mtu lock 1450 pref medium'
Warning: Facter: Could not process routing table entry: Expected a destination 
followed b

Bug#931419: network-manager: Support for multiple wired networks is confusing

[Mark Brown]

Package: network-manager
Version: 1.14.6-2
Severity: normal

On a system with multiple wired networks Network Manager displays
them separately (eg, in the system settings app I see two network
connections listed with separate settings buttons and on/off
toggles) but in actual fact there is only a single set of wired
settings and toggling one connection on toggles other wired
connections off.  Similar things happen when configuring via the
system menu.

This is not helped by the presence of a "use this connection only
for resources on its network" option (which is what I want to do
with one of the connections).

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/56 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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1
ii  libc6  2.28-10
ii  libcurl3-gnutls7.64.0-4
ii  libglib2.0-0   2.58.3-2
ii  libgnutls303.6.7-4
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2
ii  libpam-systemd 241-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-5
ii  libteamdctl0   1.28-1
ii  libudev1   241-5
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019051400
ii  policykit-10.105-25
ii  udev   241-5
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-6

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#931415: sdl2-client crashes when entering game

[Simon McVittie]

Control: severity -1 important
Control: tags -1 + patch fixed-upstream
Control: forwarded -1 
https://github.com/freeciv/freeciv/commit/5e73bcd35a8a42fa24a39ad4ac915e7f9f8f2496

On Thu, 04 Jul 2019 at 14:15:22 +0300, Marko Lindqvist wrote:
>  Some people are reporting to us in freeciv upstream that sdl2-client
> always crashes for them when entering the game. We have a fix for that
> as 0001-Fix-arithmetic-error-in-SDL2-create_line.patch (2019-07-03
> 02:18 AM) in http://www.hostedredmine.com/issues/824589 You may want
> to backport that fix.

Thanks, marking the bug accordingly (I'll leave uploading/backporting
the fix to someone who knows freeciv better than I do).

smcv

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Bas Couwenberg]

On 2019-07-04 13:52, Sergey B Kirpichev wrote:

On Thu, Jul 04, 2019 at 12:48:23PM +0200, Bas Couwenberg wrote:
Are you willing to maintain the monit backport if I sponsor the NEW 
uploads


No.  Next time _you_ may be unavailable to sponsor backport for
a buster+1.  I won't give package users impression that backports
are supported, when it's not the case.


While I'm unlikely to be unavailable for Debian work, I can't exclude 
the possibility of getting hit by a bus some time in the future.


How often do you expect to need NEW processing for monit? It doesn't 
build any library packages that get renamed for SONAME bumps for 
example.


Once monit is in backports, you won't need to pass NEW again until you 
introduce new binary package names.


For bullseye the backport hopefully won't be required to have the 
package available in stable, so it will be less of an issue if there is 
no sponsor for the initial upload of the backport because I got hit by a 
bus.



Feel free to provide backport yourself.  I also can add you as
a co-maintainer and/or step down as a package maintainer.


You should definitely not step down as maintainer, you seem to have done 
a good job maintaining the package since you got involved.


The package would benefit from team maintenance, but that assumes there 
are others willing and able to contribute to co-maintenance. This is not 
a given.


Do you know any users of the package who have contributed patches or 
other maintainer type bugreports that could be recruited to help 
co-maintain the package?


They don't need to be DDs, but it would help to provide some redundancy 
for the NEW scenario.


I'm reluctant to maintain the backport as I already maintain too many 
packages, but I also need monit in buster at $DAYJOB. So I'm in a bit of 
a bind.


My strong preference is for you to maintain the backport as you are the 
most able maintainer of the package, so I hope we can find a solution 
where I can support you with the unpleasant bureaucracy to enable you 
keep doing your work on the monit package (and its backports).


Kind Regards,

Bas

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Vincent Lefevre]

Package: perl
Version: 5.28.1-6
Severity: normal

The following does no yield any error:

  perl -e 'use strict; my $x = - Inf;'

This does not seem to be intended.

The strict(3perl) man page says:

"strict subs"
  This disables the poetry optimization, generating a compile-time
  error if you try to use a bareword identifier that's not a
  subroutine, unless it is a simple identifier (no colons) and that
  it appears in curly braces or on the left hand side of the "=>"
  symbol.

  use strict 'subs';
  $SIG{PIPE} = Plumber;   # blows up
  $SIG{PIPE} = "Plumber"; # fine: quoted string is always ok
  $SIG{PIPE} = \&Plumber; # preferred form

and the perldata(1) man page says:

Some people may wish to outlaw barewords entirely.  If you say

use strict 'subs';

then any bareword that would NOT be interpreted as a subroutine call
produces a compile-time error instead.  [...]

There does not seem to be an exception after a minus operator.

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

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

Versions of packages perl depends on:
ii  dpkg   1.19.7
ii  libperl5.285.28.1-6
ii  perl-base  5.28.1-6
ii  perl-modules-5.28  5.28.1-6

Versions of packages perl recommends:
ii  netbase  5.6

Versions of packages perl suggests:
pn  libb-debug-perl 
pn  liblocale-codes-perl
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.2.1-1.2
ii  perl-doc5.28.1-6

-- no debconf information

Bug#931417: RFP: gotico-antica-fonts -- Gotico-Antiqua, Proto-Roman, Hybrid. 15th century types between gothic and roman

[Thomas Clavier]

Package: wnpp
Severity: wishlist

* Package name: gotico-antica-fonts
  Version : 0.0.1
  Upstream Author : Jérôme Knebusch 
* URL : https://github.com/anrt-type/GoticoAntiqua
* License : OFL 1.1
  Programming Lang: na
  Description : Gotico-Antiqua, Proto-Roman, Hybrid. 15th century types 
between gothic and roman

Fifteen fonts and one set of initial letters draw from documents printed 
between 1459 and 1482. Based on a current research programme at Atelier 
national de recherche typographique (ANRT), which investigates the period 
1459-1482.

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 12:48:23PM +0200, Bas Couwenberg wrote:
> The RT ticket show that you were added to the backports ACL

It doesn't help too much: initial upload must be sponsored.

> I guess Michal
> wasn't available to sponsor your initial backports upload

Unfortunately, nobody wasn't available to sponsor for a
year.  But now we have Anti-Harassment Team.  Hooray!

> Are you willing to maintain the monit backport if I sponsor the NEW uploads

No.  Next time _you_ may be unavailable to sponsor backport for
a buster+1.  I won't give package users impression that backports
are supported, when it's not the case.

Feel free to provide backport yourself.  I also can add you as
a co-maintainer and/or step down as a package maintainer.

Bug#931416: klibc-utils: ipconfig denial of service when IP nameservers are configured on the kernel command line

[Radek Zajíc]

Package: klibc-utils
Version: 2.0.4-9
Severity: normal

Dear Maintainers,
It appears to me that there is a misalignment between initramfs network 
configuration scripts and tools in Debian and the Kernel nfsroot documentation, 
which results in a Denial of Service (networking unavailability) in the 
initramfs environment, if Debian user configures the kernel command line as per 
the kernel docs.

In the initramfs-tools-core==0.130 package, there is a file 
/usr/share/initramfs-tools/scripts/functions, which contains a 
configure_networking() function. This function claims to `support ip options, 
see linux sources Documentation/filesystems/nfs/nfsroot.txt`. This function 
does not perform network configuration on its own, it uses a ipconfig tool from 
the klibc-utils package.

When checking the latest nfsroot.txt at 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt, it 
appears to me that the latest syntax of the ip= parameter supports also DNS and 
NTP servers. Copying and pasting for your reference:

ip=:

On the other hand, the ipconfig utility, at least the version in package 
klibc-utils==2.0.4-9, does seem to support neither the DNS nor NTP options. 
Copying from 
https://salsa.debian.org/kernel-team/klibc/blob/master/usr/kinit/ipconfig/README.ipconfig
 and pasting here:

::


In general, it is quite hard to find this discrepancy as Google does not 
usually hint you at the klibc-utils package sources/readme.
If one uses static IP configuration with even a single DNS IP to the kernel 
command line, e.g.:
ip=192.0.2.2::192.0.2.1:255.255.255.0:my.host.name.com:eth0:none:8.8.8.8
the ipconfig utility fails to configure networking completely, resulting in no 
networking in the initramfs environment.

I believe the ipconfig utility should be fixed:

  *   to be in line with nfsroot.txt (supporting DNS and possibly even NTP 
configuration)
  *   not to fail if additional parameters are even introduced by the kernel 
developers and passed in on the command line by Debian users

It is true that this should be primarily handled upstream, however it is not 
clear to me how to report this issue to upstream, more specifically who is the 
upstream maintainer of this package.

(Also, there is currently no initramfs networking support for IPv6, the current 
internet protocol; there is a separate bug report/feature request for this, 
627164.)

Thank you for your attention to this issue.

With kind regards,
Radek Zajic

-- System Information:
Debian Release: 9.9
Architecture: amd64 (x86_64)

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

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.4-9

klibc-utils recommends no packages.

klibc-utils suggests no packages.

-- no debconf information

Bug#931415: sdl2-client crashes when entering game

[Marko Lindqvist]

Package: freeciv
Version: 2.6.0-2

 Some people are reporting to us in freeciv upstream that sdl2-client
always crashes for them when entering the game. We have a fix for that
as 0001-Fix-arithmetic-error-in-SDL2-create_line.patch (2019-07-03
02:18 AM) in http://www.hostedredmine.com/issues/824589 You may want
to backport that fix.

 - ML

Bug#894694: inet6-ifup-helper should not fail if IPv6 link-local address not present

[Gonzalo Peci]

I think this might be related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846583

-- 
We are hiring! 
Coya AG, Ohlauer Str. 
43, 10999 Berlin, Germany 
Vorsitzender des Aufsichtsrates: Thomas Münkel 

Vorstand: Andrew Shaw (Vorsitzender), Laura Kauther, Johannes Jacobsen 

Handelsregister: AG Charlottenburg HRB 188013 B

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Bas Couwenberg]

On 2019-07-04 12:05, Sergey B Kirpichev wrote:

On Thu, Jul 04, 2019 at 10:54:10AM +0200, Paul Gevers wrote:

Once packages can migrate normally again (somewhere next week if
everything goes as expected), monit will be back in testing and
backports is a viable option.


Feel free to do backport.

Latest one was dated Fri, 21 Dec 2018 (https://bugs.debian.org/887350).
No luck.  Have fun with the debian bureaucracy.


The RT ticket show that you were added to the backports ACL, I guess 
Michal wasn't available to sponsor your initial backports upload as he 
did for uploads to unstable in the past.


Are you willing to maintain the monit backport if I sponsor the NEW 
uploads (I'm also willing to sponsor NEW uploads to unstable)? (I'm a DD 
and also on the backports ACL)


Kind Regards,

Bas

Bug#892628: fixed in icinga 1.14.2+ds-1

[Bas Couwenberg]

fixed 892628 icinga/1.14.2+ds-1
thanks

Hi Jan,

On 2019-07-04 11:52, Jan Wagner wrote:

Am 11.03.18 um 19:20 schrieb Bas Couwenberg:

   * Update Apache configuration for 2.4 syntax.
 (closes: #892628)


after upgrading to buster I did run into the problem, that there was no
authenticating when accessing icinga. Looking into 98d8eb16 show, that
you added

Require all granted

Seems that is not what you whated, cause requireing authentication it
has to be "Require all denied".


No, "Require all granted" is the Apache 2.4 equivalent of "Allow From 
All". Which is what this issue is about.


When authentication is configured, you need "Require valid-user". Which 
the configuration also uses. "Require all granted" should probably be 
dropped instead.


That being said, Icinga 1.x is EOL upstream and as documented in the 
release-notes you should migrate to Icinga 2.


I'm not going to fix this issue in buster, if you cannot migrate to 
icinga2 soon, you can try the above to see if it fixes your issue.


Users who encounter this issue will have to fix the configuration 
themselves, or you or someone else needs to be willing to prepare as 
stable update for it.


Kind Regards,

Bas

Bug#931414: ntpsec-ntpdate: if-up script fails to sync time

[Masahiro Honda]

Package: ntpsec-ntpdate
Version: 1.1.3+dfsg1-2
Severity: normal

Dear Maintainer,


   * What led up to the situation?
 There is /etc/network/if-up.d/ntpsec-ntpdate.
 However, the time is not synchronized after the network 
 interface comes up.
 The time is synchronized when I execute ntpdate-debian.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 First, I disabled systemd-timesyncd.
   sudo systemctl disable systemd-timesyncd
 Then, I edited /etc/default/ntpsec-ntpdate.
   NTPDATE_USE_NTP_CONF="no"
   NTPOPTIONS="-b"
 Finally, I rebooted the OS.
   sudo shutdown -r now

   * What was the outcome of this action?
 The time was not synchronized after the network interface
 came up.

   * What outcome did you expect instead?
 I expected that the time will be synchronized after the
 network interface comes up.

I modified /etc/network/if-up.d/ntpsec-ntpdate.
Here is a patch.
--- ntpsec-ntpdate.orig 2019-02-14 11:30:00.88213 +
+++ ntpsec-ntpdate  2019-07-04 09:35:51.210653439 +0100
@@ -31,11 +31,12 @@
 fi
 
 service="ntpsec"
+export service
 
 invoke-rc.d --quiet "$service" stop >/dev/null 2>&1 || true
 
 # Avoid running more than one at a time
-flock -n /run/lock/ntpsec-ntpdate /usr/sbin/ntpdate-debian -s $OPTS 
2>/dev/null || :
+flock -n /run/lock/ntpsec-ntpdate /usr/sbin/ntpdate-debian $OPTS 2>/dev/null | 
logger -t ntpsec-ntpdate || :
 
 invoke-rc.d --quiet "$service" start >/dev/null 2>&1 || true
 


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.42-v7 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ntpsec-ntpdate depends on:
ii  netbase  5.6
ii  python3  3.7.3-1
ii  python3-ntp  1.1.3+dfsg1-2

ntpsec-ntpdate recommends no packages.

ntpsec-ntpdate suggests no packages.

-- Configuration Files:
/etc/default/ntpsec-ntpdate changed:
NTPDATE_USE_NTP_CONF="no"
NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 
3.debian.pool.ntp.org"
NTPOPTIONS="-b"
IGNORE_DHCP=""


-- no debconf information

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 10:31:07AM +0200, Bas Couwenberg wrote:
> We rely on monit at $DAYJOB, so I want to help you get monit back in buster.

Am afraid, there is no chance for monit to enter buster.  Sorry for this
situation, but I believe this is not just my fault (see this bug
thread).  Anyway, if you know someone, who can offer better support
for monit in the debian - just tell.  I will appreciate any help
and/or may step down as a maintainer.

> I'm somewhat reluctantly willing to maintain the monit backport
> if you don't want to main the package in backports.

Sure, do.

> Are you willing to maintain monit in backports if the stable update is not
> accepted?

I will not try again to spend my time for providing backports.  Feel
free to waste your time.

Bug#931413: fetch-ldap-cert renews Debian Edu PKI on clients on every reboot

[Mike Gabriel]

Package: debian-edu-config
Severity: serious
Version: 2.10.65

The former version of fetch-ldap-cert (stretch and before) retrieved  
the LDAP servers pub cert only once, that is on first boot on the  
Debian Edu network. A machine booted in one network would not have  
been reusable in some other Debian Edu network.


The reasoning behind this was:

```
11:54 < sunweaver> pere: the original approach of fetch-ldap-cert was:  
retrieve the cert from TJENER on first usage on the network and then  
remember it, right?
11:54 < sunweaver> So that a prepped notebook would belong to the  
first TJENER where it was first booted with. Right?
11:55 < sunweaver> The new fetch-ldap-cert always overwrites the LDAP  
cert and Debian Edu machines can migrate from one school to another.

11:55 < sunweaver> at least from what I read from the code...
11:55 < sunweaver> I found the previous approach more charming and "secure".
11:56 < sunweaver> in a world where GRUB is md5 protected, you would  
not be able to retrieve local data from the notebook.

11:57 < pere> sunweaver: yes.
11:58 < pere> sunweaver: the idea was that a stolen machine would not  
pass out and validate password from whoever happened to be able to  
provide a certificate, but stick to the one it was using during  
installation.

```

For migrating a Debian Edu workstation from one D-E network to  
another, one would have had to remove the  
/etc/ldap/ssl/ldap-server-pubkey.pem and reboot the machine at the new  
location.


With the latest (Debian Edu buster) implementation, the  
debian-edu-bundle.crt file is retrieved on every reboot and replaces  
the previously fetch cert file. IMHO, we should consider this as a  
severe regression that needs to be fixed.


Feedback? Opinions?

@Wolfgang: don't get me wrong, I am so happy about the new Debian Edu  
PKI stuff. That was really well done. I am just nitpicking on bits and  
pieces I stumble over while migrating a customer's network and report  
things here. Please don't take my "complaints" personally, only  
technically. Thank you!


Thanks+Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpz6dGmClCcZ.pgp
Description: Digitale PGP-Signatur

Bug#629359: Mettre à jour votre compte

[info]

--
Veuillez noter que votre compte de messagerie Web est actuellement 
encombré. Nous mettons à niveau tous les comptes de messagerie Web. 
Veuillez vérifier votre courrier Web aujourd'hui avec le lien 
ci-dessous.


https://forms.app/form/5d1dba4f2f39f2237d4ceec2

© 2019 Centre de vérification de messagerie Web

Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sergey B Kirpichev]

On Thu, Jul 04, 2019 at 10:54:10AM +0200, Paul Gevers wrote:
> Once packages can migrate normally again (somewhere next week if
> everything goes as expected), monit will be back in testing and
> backports is a viable option.

Feel free to do backport.

Latest one was dated Fri, 21 Dec 2018 (https://bugs.debian.org/887350).
No luck.  Have fun with the debian bureaucracy.

Bug#928287: qutip debian packaging

[Gürkan Myczko]

Ah I looked at salsa.debian.org, but forgot to check NEW queue...


It's been uploaded, waiting in the NEW queue.


Very nice, thanks for it! We need that!


Drew

Bug#892628: fixed in icinga 1.14.2+ds-1

[Jan Wagner]

Hi Bas,

Am 11.03.18 um 19:20 schrieb Bas Couwenberg:
>* Update Apache configuration for 2.4 syntax.
>  (closes: #892628)

after upgrading to buster I did run into the problem, that there was no
authenticating when accessing icinga. Looking into 98d8eb16 show, that
you added

Require all granted

Seems that is not what you whated, cause requireing authentication it
has to be "Require all denied".

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--





signature.asc
Description: OpenPGP digital signature

Bug#931412: O: xmms2 -- Client/server based media player system

[Benjamin Drung]

Package: wnpp
Severity: normal

I intend to orphan the xmms2 package, because I am not using it any
more and lack enough time to properly maintain the package.

The package description is:
 XMMS2 is a redesign of the XMMS music player. It features a client-server
 model, allowing multiple (even simultaneous!) user interfaces, both textual
 and graphical. All common audio formats are supported using plug-ins. On top of
 this, there is a flexible media library to organize your music.
 .
 This package is a metapackage depending on various other XMMS2 packages.
 Installing this package gets you a command line client and enables XMMS2
 playback of Ogg Vorbis and MP3 files from local and remote sources.

Bug#931411: samba-common-bin: samba-tool user create error with unicode characters in the names

[Pisch Tamás]

Package: samba-common-bin
Version: 2:4.9.5+dfsg-5
Severity: normal

Dear Maintainer,

when I give the command, for example
samba-tool user create test pwd --surname Vezetéknév --givenname Keresztnév
I get the following error message:
ERROR(): Failed to add user
'teszttanar3':  - 'ascii' codec can't decode byte 0xc3 in position 16:
ordinal not in range(128)
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/user.py", line 425, in run
smartcard_required=smartcard_required)
  File "/usr/lib/python2.7/dist-packages/samba/samdb.py", line 490, in newuser
force_password_change_at_next_login_req)
  File "/usr/lib/python2.7/dist-packages/samba/samdb.py", line 606, in
setpassword
""" % (user_dn, base64.b64encode(pw).decode('utf-8'))
On the Samba list, somebody suggested to use newer Samba version,
because it is improved. Samba 4.10 can (or in default?) uses python3,
and with it, I could use unicode
characters. Ok, but I would like to use Debian 10, with official packages.

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

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

Versions of packages samba-common-bin depends on:
ii  libbsd00.9.1-2
ii  libc6  2.28-10
ii  libldap-2.4-2  2.4.47+dfsg-3
ii  libncurses66.1+20181013-2
ii  libpopt0   1.16-12
ii  libreadline7   7.0-5
ii  libtalloc2 2.1.14-2
ii  libtdb11.3.16-2+b1
ii  libtevent0 0.9.37-1
ii  libtinfo6  6.1+20181013-2
ii  libwbclient0   2:4.9.5+dfsg-5
ii  python 2.7.16-1
ii  python-samba   2:4.9.5+dfsg-5
ii  python2.7  2.7.16-2
ii  samba-common   2:4.9.5+dfsg-5
ii  samba-libs 2:4.9.5+dfsg-5

Versions of packages samba-common-bin recommends:
ii  samba-dsdb-modules  2:4.9.5+dfsg-5

Versions of packages samba-common-bin suggests:
pn  heimdal-clients  

-- no debconf information

I have sent this bug report with reportbug, from the Debian host, but
I'm not sure, whether you received my mail, and the bug haven't
appeared on here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=samba-common-bin

Bug#444874: nm-openvpn changes gateway unasked

[Wouter Verhelst]

Package: network-manager-openvpn
Followup-For: Bug #444874

Hi,

I notice that the GNOME UI for this package now includes an option "Use
this connection for sources on their network only" (translated from
Dutch, sorry), which if enabled removes the default route, but is not
enabled by default, not even when importing an OpenVPN configuration
file that does not have the "redirect-gateway" option set, as I would
expect.

However, it still adds a static route, using the default gateway, to the
OpenVPN server. If the OpenVPN server is not available over the default
gateway but only over another network, then this breaks the connection,
and that cannot be fixed using the GUI.

I filed an upstream bug report about this at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/204

Regards,

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

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

Versions of packages network-manager-openvpn depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2
ii  libnm0   1.14.6-2
ii  network-manager  1.14.6-2
ii  openvpn  2.4.7-1

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#931410: O: packaging-dev -- convenient tools to develop packages

[Benjamin Drung]

Package: wnpp
Severity: normal

I intend to orphan the packaging-dev package.

The package description is:
 This metapackage depends on common packages useful for the development of
 Debian-format packages, including patch management systems, build systems,
 packaging macros, helpful scripts for developers, and tools for building and
 testing packages.
 .
 This metapackage provides tools for packaging, rather than the development of
 software. No other package should depend or build-depend on this package.

Bug#931409: O: lxmms2 -- control XMMS2 with a LIRC compatible remote control

[Benjamin Drung]

Package: wnpp
Severity: normal

I intend to orphan the lxmms2 package, because I do not use it any more
and lack enough time to properly maintain the package.

The package description is:
 lxmms2 is a tiny XMMS2 client to control XMMS2 with a LIRC compatible remote
 control. Following actions are supported:
  - play (starts playback)
  - pause (pauses playback)
  - toggle_play_pause (toggles pause and starts playback if XMMS2 is not playing
at all)
  - toggle_pause (toggles pause)
  - stop (stops playback)
  - next (advances to the next track)
  - prev (goes back to the previous track)
  - volume_up (increases the volume)
  - volume_down (decreases the volume)

Bug#931408: node-fstream: CVE-2019-13173

[Salvatore Bonaccorso]

Source: node-fstream
Version: 1.0.10-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for node-fstream.

CVE-2019-13173[0]:
| fstream before 1.0.12 is vulnerable to Arbitrary File Overwrite.
| Extracting tarballs containing a hardlink to a file that already
| exists in the system, and a file that matches the hardlink, will
| overwrite the system's file with the contents of the extracted file.
| The fstream.DirWriter() function is vulnerable.

In commit [2], there is open question if that is sufficient.

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-13173
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13173
[1] https://www.npmjs.com/advisories/886
[2] 
https://github.com/npm/fstream/commit/6a77d2fa6e1462693cf8e46f930da96ec1b0bb22

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#821111: nginx: Failure to remove socket due to Debian's method of stopping

[Andreas Kirbach]

On Sat, 15 Dec 2018 23:03:27 -0600 James Renken 
wrote:
> This bug is still present for me in version 1.14.1-1~bpo9+1.
I can confirm this as well; nginx 1.14.1-1~bpo9+1 does not restart
properly as sockets are not removed upon stop and nginx complains that
the address is already in use when restarting.
-- 
Andreas Kirbach
Technischer Leiter

forumhome GmbH & Co. KG
Bruchstr. 54a
67098 Bad Dürkheim
Tel.: +49-6322-91 995-15
Fax:  +49-6322-91 995-19

akirb...@forumhome.com
www.forumhome.com

Sitz der Gesellschaft: Bad Dürkheim
Handelsregister: Ludwigshafen/ Rhein HRA 60968
USt-Id: DE 285 908 418
Persönlich haftende Gesellschafterin: OSV OnlineService Verwaltungs GmbH

OSV OnlineService-Verwaltungs GmbH
Sitz der Gesellschaft: Bad Dürkheim
Handelsregister: Ludwigshafen/ Rhein HRB 63178
Geschäftsführer: Carsten Grentrup

--
--
Forumhome sucht Praktikanten im Bereich Online-Marketing, Webdesign und
Webbasierte Softwareentwicklung!
Interesse? Informieren Sie sich unter
http://de.forumhome.com/content/10-jobs und schicken Sie uns Ihre
Bewerbungsunterlagen an j...@forumhome.com
Wir freuen uns auf Sie!
--
--

Diese E-Mail enthält vertrauliche oder rechtlich geschützte Informationen.
Wenn Sie nicht der beabsichtigte Empfänger oder dessen Vertreter sind,
informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail.
Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der
enthaltenen Informationen ist nicht gestattet.

The information contained in this message is confidential or protected
by law. If you are not the intended recipient, please contact the sender
and delete this message.
Any unauthorised copying of this message or unauthorised distribution of
the information contained herein is prohibited.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Bug#931407: ITP: r-bioc-biocfilecache -- GNU R management of files across sessions

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-biocfilecache -- GNU R management of files across sessions
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-biocfilecache
  Version : 1.8.0
  Upstream Author : Lori Shepherd,
* URL : https://bioconductor.org/packages/BiocFileCache/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : GNU R management of files across sessions
 This package creates a persistent on-disk cache of files
 that the user can add, update, and retrieve. It is useful for
 managing resources (such as custom Txdb objects) that are costly
 or difficult to create, web resources, and data files used across
 sessions.

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