date:20190726

Package: wnpp

The current maintainer of cpufrequtils, Mattia Dongili ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: cpufrequtils
Binary: cpufrequtils, libcpufreq0, libcpufreq-dev
Version: 008-1.1
Maintainer: Mattia Dongili 
Build-Depends: debhelper-compat (= 12)
Architecture: any
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 41c94bfa4a65aecb0760c96f0438555a 2006 cpufrequtils_008-1.1.dsc
 e60e0b07810b51babd4447ae07285e7d 52128 cpufrequtils_008.orig.tar.bz2
 b3b23640201b4e36095ca3770d844e75 25440 cpufrequtils_008-1.1.debian.tar.xz
Checksums-Sha256:
 0d2f838023f885d0744cc91c31a6d4a4a0e6f475d09b58f1e3cdbb4f894309e0 2006 
cpufrequtils_008-1.1.dsc
 638fb067f71166043dff2e493a9d0295300fb73b6d9add052e930d3d42a37efd 52128 
cpufrequtils_008.orig.tar.bz2
 42de965a90af940d921aa058b336ec25998345e7c11bd128ceeb0792fbf8c78c 25440 
cpufrequtils_008-1.1.debian.tar.xz
Homepage: http://kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
Package-List: 
 cpufrequtils deb admin optional 
arch=alpha,amd64,arm64,armel,armhf,hppa,hurd,i386,ia64,kbsd64,kbsd32,m68k,mips,mips64el,mipsel,s390x,sh4,sparc64,x32
 libcpufreq-dev deb libdevel optional arch=any
 libcpufreq0 deb libs optional arch=any
Directory: pool/main/c/cpufrequtils
Priority: source
Section: admin

Package: cpufrequtils
Version: 008-1.1
Installed-Size: 178
Maintainer: Mattia Dongili 
Architecture: amd64
Depends: libc6 (>= 2.3), libcpufreq0 (>= 006), debconf (>= 0.5) | debconf-2.0, 
lsb-base (>= 3.0)
Pre-Depends: init-system-helpers (>= 1.54~)
Description-en: utilities to deal with the cpufreq Linux kernel feature
 This package contains two utilities for inspecting and setting the
 CPU frequency through both the sysfs and procfs CPUFreq kernel
 interfaces.
 .
 By default, it also enables CPUFreq at boot time if the correct CPU
 driver is found.
Description-md5: 52dad6bb1cd00cd7cfe3ebb7d3ae3f80
Homepage: http://kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
Tag: admin::hardware, admin::kernel, admin::power-management, devel::lang:c,
 devel::library, hardware::detection, hardware::power,
 implemented-in::c, implemented-in::shell, interface::commandline,
 role::devel-lib, role::program, scope::utility, use::configuring,
 use::monitor
Section: admin
Priority: optional
Filename: pool/main/c/cpufrequtils/cpufrequtils_008-1.1_amd64.deb
Size: 35976
MD5sum: 21384628bf66b661d35aa45ae69b52ba
SHA256: c67acffb8dad6276d868335c4b8df09efcae39aed3f49048dfbd247d79d17aff

Package: libcpufreq0
Source: cpufrequtils
Version: 008-1.1
Installed-Size: 45
Maintainer: Mattia Dongili 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description-en: shared library to deal with the cpufreq Linux kernel feature
 This library provide an unified method to access the CPUFreq kernel
 interface.
Description-md5: fcc22fed9052f900ec2f715653b1e465
Homepage: http://kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/c/cpufrequtils/libcpufreq0_008-1.1_amd64.deb
Size: 13360
MD5sum: 7d0083105f152562cc92af427b87504e
SHA256: 110964767af33bbc26577fb8b380f767f4ff62bb652385b09244dac106dbe5b3

Package: libcpufreq-dev
Source: cpufrequtils
Version: 008-1.1
Installed-Size: 47
Maintainer: Mattia Dongili 
Architecture: amd64
Depends: libcpufreq0 (= 008-1.1)
Description-en: development files to deal with the cpufreq Linux kernel feature
 This package provides everything that is needed for developing own
 programs using libcpufreq.
Description-md5: 2b21fbbb72fdd73ad7d91131094b262f
Homepage: http://kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.html
Tag: admin::hardware, devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/c/cpufrequtils/libcpufreq-dev_008-1.1_amd64.deb
Size: 13668
MD5sum: fc1a29d02581033ddb101ca1144d3954
SHA256: 481af8f83ac2404713c625ce03b6e5372801d6bb59b7b00e2c81ba9242ea5b24

Bug#933160: O: cpufreqd -- fully configurable daemon for dynamic frequency and voltage scaling

Package: wnpp

The current maintainer of cpufreqd, Mattia Dongili ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: cpufreqd
Binary: cpufreqd
Version: 2.4.2-2.1
Maintainer: Mattia Dongili 
Build-Depends: debhelper (>= 7), quilt, automake, libtool, libsensors4-dev, 
libcpufreq-dev [!powerpc !ppc64 !ppc64el], libcpupower-dev [powerpc ppc64 
ppc64el], libsysfs-dev (>= 2.0.0)
Architecture: any
Standards-Version: 3.8.4
Format: 3.0 (quilt)
Files:
 7580a2eaaeb2863c38acde9dcd6595d7 1904 cpufreqd_2.4.2-2.1.dsc
 038a3254044ead9944d9a04bcc94b5f4 66365 cpufreqd_2.4.2.orig.tar.bz2
 2f45ad384cfb356b912a491399a27213 11224 cpufreqd_2.4.2-2.1.debian.tar.xz
Checksums-Sha256:
 13c758cb73d6d3455ea9d52b9a55b46b3100c8941b6746ee161e3cb4173f9c84 1904 
cpufreqd_2.4.2-2.1.dsc
 27632ba27c22463089dc329b0afbeabd26c176e35f8711ae2edb0d490a86d7f2 66365 
cpufreqd_2.4.2.orig.tar.bz2
 e235ccf8b09db89b9a358cd3747a99a7ef81ff866110d7ea24829e3c3a7ae96d 11224 
cpufreqd_2.4.2-2.1.debian.tar.xz
Homepage: http://sourceforge.net/projects/cpufreqd
Package-List: 
 cpufreqd deb admin optional arch=any
Directory: pool/main/c/cpufreqd
Priority: source
Section: admin

Package: cpufreqd
Version: 2.4.2-2.1
Installed-Size: 318
Maintainer: Mattia Dongili 
Architecture: amd64
Depends: libc6 (>= 2.14), libcpufreq0 (>= 001), libsensors5 (>= 1:3.5.0), 
libsysfs2 (>= 2.1.0+repack), lsb-base (>= 3.0)
Recommends: acpid
Suggests: cpufrequtils
Conflicts: cpudyn, powernowd
Description-en: fully configurable daemon for dynamic frequency and voltage 
scaling
 cpufreqd is meant to be a replacement of the speedstep applet you can find on
 some other OS, it monitors the system status and selects the most appropriate
 CPU level.  It is fully configurable and easily extensible through the many
 available plug-ins (more to come).
 Despite its name it can be used to control also the NForce2-Atxp1 voltage
 regulator and the core and memory clock for NVidia cards (see README.Debian).
 .
 You need a CPUFreq driver and either APM, ACPI (a recent version) or PMU
 enabled in your kernel in order for this daemon to work.
Description-md5: 2e6607a4cd24cc140a7c1cd9613eaaab
Homepage: http://sourceforge.net/projects/cpufreqd
Tag: admin::boot, admin::hardware, hardware::laptop, hardware::power,
 hardware::power:acpi, hardware::power:apm, interface::daemon,
 role::program, scope::utility, use::configuring
Section: admin
Priority: optional
Filename: pool/main/c/cpufreqd/cpufreqd_2.4.2-2.1_amd64.deb
Size: 71712
MD5sum: daf1c6385dae2aadba44611e9f3834d6
SHA256: 706ed05cc5d314469ba1aa14f90975b7ee6cc98b649eb9b399b9e2d487d03bea

Package: cpufreqd
Source: cpufreqd (2.4.2-2)
Version: 2.4.2-2+b2
Installed-Size: 319
Maintainer: Mattia Dongili 
Architecture: amd64
Depends: libc6 (>= 2.14), libcpufreq0 (>= 001), libsensors5 (>= 1:3.5.0), 
libsysfs2 (>= 2.1.0+repack), lsb-base (>= 3.0)
Recommends: acpid
Suggests: cpufrequtils
Conflicts: cpudyn, powernowd
Description-en: fully configurable daemon for dynamic frequency and voltage 
scaling
 cpufreqd is meant to be a replacement of the speedstep applet you can find on
 some other OS, it monitors the system status and selects the most appropriate
 CPU level.  It is fully configurable and easily extensible through the many
 available plug-ins (more to come).
 Despite its name it can be used to control also the NForce2-Atxp1 voltage
 regulator and the core and memory clock for NVidia cards (see README.Debian).
 .
 You need a CPUFreq driver and either APM, ACPI (a recent version) or PMU
 enabled in your kernel in order for this daemon to work.
Description-md5: 2e6607a4cd24cc140a7c1cd9613eaaab
Homepage: http://sourceforge.net/projects/cpufreqd
Tag: admin::boot, admin::hardware, hardware::laptop, hardware::power,
 hardware::power:acpi, hardware::power:apm, interface::daemon,
 role::program, scope::utility, use::configuring
Section: admin
Priority: optional
Filename: pool/main/c/cpufreqd/cpufreqd_2.4.2-2+b2_amd64.deb
Size: 71860
MD5sum: 8f652dc77922160f60ea43abcc1bd046
SHA256: 7a99ceb62889cfd6e7b586092139047e63beef4c4d563bfade3ebc6c15804940

Bug#933154: Updating the acpica-unix Uploaders list

Source: acpica-unix
Version: 20190509-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mattia Dongili  has retired, so can't work on
the acpica-unix package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#933155: Updating the uml-utilities Uploaders list

Source: uml-utilities
Version: 20070815.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mattia Dongili  has retired, so can't work on
the uml-utilities package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#933158: Updating the xserver-xorg-input-synaptics Uploaders list

Source: xserver-xorg-input-synaptics
Version: 1.9.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mattia Dongili  has retired, so can't work on
the xserver-xorg-input-synaptics package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#920561: emacs: Still present in 1:26.1+1-3.3

2019-07-26 Thread John Hasler

Package: emacs
Version: 1:26.1+1-3.3
Followup-For: Bug #920561

Dear Maintainer,

I upgraded Emacs and this bug appeared.  Same symptoms as seen by the OP.
His fix worked.

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.3

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#933087: New upstream release 12.1.0

2019-07-26 Thread Dmitry Smirnov

On Friday, 26 July 2019 11:56:12 PM AEST Ulises Vitulli wrote:
> Upstream has released a new version of gitlab-runner 12.1.0.
> This version is particularly relevant for the introduction in runners of
> the Custom executor capability.
> 
> Please consider upgrading it!

Thanks, I'll see what I can do. However my attempt to build 12.1.0 revealed 
that all tests for custom executor are failing, e.g.

  * https://gitlab.com/gitlab-org/gitlab-runner/issues/4538
  * https://gitlab.com/gitlab-org/gitlab-runner/issues/4539

-- 
Best wishes,
 Dmitry Smirnov.

---

Laws alone can not secure freedom of expression; in order that every man
present his views without penalty there must be spirit of tolerance in the
entire population.
-- Albert Einstein


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

Bug#933153: linux-image-4.19.0-5-amd64: soft lockup cpu stuck

2019-07-26 Thread Joe B. McEntire

Package: src:linux
Version: 4.19.37-5+deb10u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?  Time
   * What exactly did you do (or not do) that was effective (or
 ineffective)? It was after upgrading to Buster, I changed kernel boot
params removing kvm stuff for gpu passthough, etc
   * What was the outcome of this action? Ranges from minor annoyance to making
applications like games crash
   * What outcome did you expect instead? stability :)

Error generally looks like:
Message from syslogd@master at Jul 26 12:56:02 ...
 kernel:[226137.665230] watchdog: BUG: soft lockup - CPU#17 stuck for 23s!
[libvirtd:7893]

Message from syslogd@master at Jul 26 12:56:02 ...
 kernel:[226137.681225] watchdog: BUG: soft lockup - CPU#23 stuck for 23s!
[kworker/23:0:6856]

Message from syslogd@master at Jul 26 12:56:30 ...
 kernel:[226165.665295] watchdog: BUG: soft lockup - CPU#17 stuck for 23s!
[libvirtd:7893]

Message from syslogd@master at Jul 26 12:56:30 ...
 kernel:[226165.681289] watchdog: BUG: soft lockup - CPU#23 stuck for 23s!
[kworker/23:0:6856]

I run 2 Xeon E5-2620 CPUs in this system with 64GB RAM

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



-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/System-root ro quiet 
splash apparmor=1 security=apparmor

** Tainted: PWOEL (29185)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.
 * Kernel has detected soft lockup before.

** Kernel log:
[226169.517462] CR2: 7f073877b010 CR3: 001030912002 CR4: 
000626f0
[226169.517464] Call Trace:
[226169.517475]  ? flush_tlb_func_common.constprop.9+0x210/0x210
[226169.517478]  flush_tlb_mm_range+0xd0/0x120
[226169.517483]  arch_tlb_finish_mmu+0xbd/0x100
[226169.517486]  tlb_finish_mmu+0x1f/0x30
[226169.517488]  unmap_region+0xdd/0x110
[226169.517492]  do_munmap+0x27f/0x430
[226169.517495]  vm_munmap+0x5f/0xa0
[226169.517498]  __x64_sys_munmap+0x22/0x30
[226169.517503]  do_syscall_64+0x53/0x110
[226169.517510]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[226169.517513] RIP: 0033:0x7f0786a6e1d7
[226169.517514] Code: 10 e9 67 ff ff ff 0f 1f 44 00 00 48 8b 15 b1 6c 0c 00 f7 
d8 64 89 02 48 c7 c0 ff ff ff ff e9 6b ff ff ff b8 0b 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 89 6c 0c 00 f7 d8 64 89 01 48
[226169.517515] RSP: 002b:7fffb6091068 EFLAGS: 0202 ORIG_RAX: 
000b
[226169.517517] RAX: ffda RBX: 063f RCX: 
7f0786a6e1d7
[226169.517518] RDX: 55f136255a60 RSI: 0004 RDI: 
7f06ee93e000
[226169.517519] RBP: 7f06ed704050 R08: 55f136255a60 R09: 
7f073877b000
[226169.517520] R10: 0040 R11: 0202 R12: 
55f1352162f0
[226169.517521] R13: 0006 R14:  R15: 

[226179.485519] nfs: server storage not responding, timed out
[226184.349339] [ cut here ]
[226184.349345] NETDEV WATCHDOG: enp6s0f0 (igb): transmit queue 1 timed out
[226184.349376] WARNING: CPU: 16 PID: 0 at net/sched/sch_generic.c:461 
dev_watchdog+0x20d/0x220
[226184.349377] Modules linked in: vhost_net vhost tap tun rfcomm devlink 
rpcsec_gss_krb5 nfsv4 dns_resolver nfs lockd grace fscache 
nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT xt_tcpudp ip6t_rpfilter 
ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack nft_counter 
nft_chain_nat_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 bridge stp llc 
nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nft_chain_route_ipv4 nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink 
bnep binfmt_misc nls_ascii nls_cp437 vfat fat snd_hda_codec_hdmi intel_rapl 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel intel_cstate vfio_pci vfio_virqfd 
vfio_iommu_type1 vfio irqbypass nvidia_drm(POE) drm_kms_helper btusb btrtl 
btbcm btintel
[226184.349442]  intel_uncore bluetooth drm snd_hda_codec_realtek efi_pstore 
intel_rapl_perf snd_hda_codec_generic efivars pcspkr nvidia_modeset(POE) 
uvcvideo drbg joydev videobuf2_vmalloc ansi_cprng videobuf2_memops 
videobuf2_v4l2 snd_usb_audio videobuf2_common ecdh_generic videodev 
snd_hda_intel snd_usbmidi_lib snd_hda_codec snd_rawmidi rfkill snd_seq_device 
media snd_hda_core iTCO_wdt snd_hwdep iTCO_vendor_support snd_pcm snd_timer snd 
mei_me sg mei soundcore ioatdma uinput pcc_cpufreq evdev nvidia(POE) 
ipmi_devintf ipmi_msghandler auth_rpcgss sunrpc parport_pc ppdev lp parport 
efivarfs ip_tables x_tables autofs4 ext4 hid_steam crc16 mbcache jbd2 fscrypto 
ecb dm_mod sr_mod sd_mod cdrom btrfs xor

Bug#931199: buster-pu: freeorion/0.4.8-1+deb10u1

2019-07-26 Thread Markus Koschany

retitle 931199 buster-pu: package freeorion/0.4.8-1+deb10u1
user release.debian@packages.debian.org
usertags 931199 - unblock
usertags 931199 pu
tags 931199 buster
thanks

Dear release team,

please find attached the debdiff between the version in Buster and
testing that fixes the load and save crash bug in freeorion.

Regards,

Markus
diff -Nru freeorion-0.4.8/debian/changelog freeorion-0.4.8/debian/changelog
--- freeorion-0.4.8/debian/changelog2018-08-31 17:09:10.0 +0200
+++ freeorion-0.4.8/debian/changelog2019-07-27 03:24:19.0 +0200
@@ -1,3 +1,22 @@
+freeorion (0.4.8-1+deb10u1) buster; urgency=medium
+
+  * Backport "Fix save or load game crash" patch to Buster.
+
+ -- Markus Koschany   Sat, 27 Jul 2019 03:24:19 +0200
+
+freeorion (0.4.8-3) unstable; urgency=medium
+
+  * Really fix save or load game crash. (Closes: #930417)
+
+ -- Markus Koschany   Sun, 23 Jun 2019 01:52:26 +0200
+
+freeorion (0.4.8-2) unstable; urgency=medium
+
+  * Fix save or load game crash. Thanks to Michal Mauser for the report and
+Bernhard Übelacker for the investigation. (Closes: #930417)
+
+ -- Markus Koschany   Sun, 16 Jun 2019 01:02:41 +0200
+
 freeorion (0.4.8-1) unstable; urgency=medium
 
   * New upstream version 0.4.8.
diff -Nru freeorion-0.4.8/debian/patches/debian-bug-930417.patch 
freeorion-0.4.8/debian/patches/debian-bug-930417.patch
--- freeorion-0.4.8/debian/patches/debian-bug-930417.patch  1970-01-01 
01:00:00.0 +0100
+++ freeorion-0.4.8/debian/patches/debian-bug-930417.patch  2019-07-27 
02:08:52.0 +0200
@@ -0,0 +1,147 @@
+From: Markus Koschany 
+Date: Sun, 16 Jun 2019 01:10:41 +0200
+Subject: debian-bug-930417
+
+Bug-Debian: https://bugs.debian.org/930417
+Origin: 
https://github.com/freeorion/freeorion/pull/2366/commits/1e94e406fa309c60c4b68ef08b424b65a7bd0e4d
+---
+ server/SaveLoad.cpp | 70 +
+ 1 file changed, 39 insertions(+), 31 deletions(-)
+
+diff --git a/server/SaveLoad.cpp b/server/SaveLoad.cpp
+index ecb73a3..37614d7 100644
+--- a/server/SaveLoad.cpp
 b/server/SaveLoad.cpp
+@@ -333,8 +333,13 @@ void LoadGame(const std::string& filename, 
ServerSaveGameData& server_save_game_
+ if (!ifs)
+ throw std::runtime_error(UNABLE_TO_OPEN_FILE);
+ 
+-try {
+-// first attempt binary deserialziation
++std::string signature(5, '\0');
++if (!ifs.read([0], 5))
++throw std::runtime_error(UNABLE_TO_OPEN_FILE);
++boost::iostreams::seek(ifs, 0, std::ios_base::beg);
++
++if (strncmp(signature.c_str(), "> BOOST_SERIALIZATION_NVP(ignored_save_preview_data);
+@@ -350,14 +355,10 @@ void LoadGame(const std::string& filename, 
ServerSaveGameData& server_save_game_
+ Deserialize(ia, universe);
+ 
+ DebugLogger() << "Done deserializing";
+-} catch (...) {
+-// if binary deserialization failed, try more-portable XML 
deserialization
+-
+-// reset to start of stream (attempted binary serialization will 
have consumed some input...)
+-boost::iostreams::seek(ifs, 0, std::ios_base::beg);
+-
++} else {
+ // create archive with (preallocated) buffer...
+ freeorion_xml_iarchive xia(ifs);
++DebugLogger() << "Reading XML iarchive";
+ // read from save file: uncompressed header serialized data, with 
compressed main archive string at end...
+ // deserialize uncompressed save header info
+ xia >> BOOST_SERIALIZATION_NVP(ignored_save_preview_data);
+@@ -458,18 +459,21 @@ void LoadGalaxySetupData(const std::string& filename, 
GalaxySetupData& galaxy_se
+ if (!ifs)
+ throw std::runtime_error(UNABLE_TO_OPEN_FILE);
+ 
+-try {
+-// first attempt binary deserialziation
++std::string signature(5, '\0');
++if (!ifs.read([0], 5))
++throw std::runtime_error(UNABLE_TO_OPEN_FILE);
++boost::iostreams::seek(ifs, 0, std::ios_base::beg);
++
++if (strncmp(signature.c_str(), "> BOOST_SERIALIZATION_NVP(ignored_save_preview_data);
+ ia >> BOOST_SERIALIZATION_NVP(galaxy_setup_data);
+ 
+-} catch(...) {
+-// if binary deserialization failed, try more-portable XML 
deserialization
+-
+-// reset to start of stream (attempted binary serialization will 
have consumed some input...)
+-boost::iostreams::seek(ifs, 0, std::ios_base::beg);
++} else {
++DebugLogger() << "Attempting XML deserialization...";
+ freeorion_xml_iarchive ia(ifs);
+ 
+ ia >> BOOST_SERIALIZATION_NVP(ignored_save_preview_data);
+@@ -498,8 +502,13 @@ void LoadPlayerSaveHeaderData(const std::string& 
filename, std::vector> BOOST_SERIALIZATION_NVP(ignored_galaxy_setup_data);
+ ia >> BOOST_SERIALIZATION_NVP(ignored_server_save_game_data);
+ ia >>

Bug#933152: dpkg-dev: DEP3 spam with single-debian-patch

2019-07-26 Thread Adam Borowski

Package: dpkg-dev
Version: 1.19.7
Severity: normal

If a package has single-debian-patch in debian/source/options, quilt is not
supposed to be used (it is technically still used because there's no
quilt-less non-native format, and 3.0 has many upsides besides the downside
of quilt).  Yet, the produced single patch still receives DEP3 headers.

These headers won't ever be filled out (there's no chance to do so without
employing additional steps), are likely to contain invalid/outdated data,
and tend to leak some state of intermediate development of the package (such
as "try 17", personal notes, profanity, etc).  These headers pick random
pieces of such state, and not even update those bits in subsequent
invocations of dpkg-buildpackage -S unless some part of the upstream tree
got changed again.  And, the quiltage is not visible to modern tools such as
git -- it's a mere implementation detail.

Thus, these headers do no good, and can do harm -- and in any case, they're
spam.  Thus, please suppress these headers if single-debian-patch is used.


Thanks for your work!
Meow.
-- Package-specific info:

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

Kernel: Linux 5.2.1-00036-gf2c1d208af28 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-dev depends on:
ii  binutils  2.32.51.20190707-1
ii  bzip2 1.0.6-9.2
ii  libdpkg-perl  1.19.7
ii  make  4.2.1-1.2
ii  patch 2.7.6-5
ii  perl  5.28.1-6
ii  tar   1.30+dfsg-6
ii  xz-utils  5.2.4-1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.6
ii  clang-8 [c-compiler] 1:8.0.1~+rc4-1
ii  fakeroot 1.23-1
ii  gcc  4:9-20181127-1
ii  gcc-9 [c-compiler]   9.1.0-10
ii  gnupg2.2.17-3
ii  gpgv 2.2.17-3
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2019.06.25

-- no debconf information

Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-26 Thread Otto Kekäläinen

Package: mariadb-10.3
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

The version of the package currently FTBFS on the riscv64 port.

>From 
>https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0


/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
undefined reference to `__atomic_fetch_or_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
undefined reference to `__atomic_fetch_or_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
undefined reference to `__atomic_compare_exchange_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
/usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: 
librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
more undefined references to `__atomic_compare_exchange_1' follow
collect2: error: ld returned 1 exit status

If you are an RISC expert, feel free to fork
https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
make a merge request.

Thanks,

Otto

Bug#925432: tdiary-mode: unowned files after purge (policy 6.8, 10.8): /usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/*

2019-07-26 Thread Tatsuya Kinoshita

Control: tags -1 + patch

On March 25, 2019 at 1:33AM +0100, anbe (at debian.org) wrote:
> 1m8.3s ERROR: FAIL: Package purging left files on system:
>   /usr/share/emacs/site-lisp/elpa/ not owned
>   /usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/   not owned
>   /usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/Install.log.gz
>  not owned
>   /usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/http.el -> 
> /usr/share/emacs/site-lisp/elpa-src/tdiary-mode-20170123.2324//http.el  not 
> owned
>   /usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/http.elc   not 
> owned

  - 
https://salsa.debian.org/ruby-team/tdiary-contrib/commit/55c35f57e73d41e125f23ae1c65bcccd79833900

It seems the old stuff 
mistakenly revived, so incompletely dh_elpa-fied.

Please remove it to fix this bug.

```
--- a/debian/tdiary-mode.emacsen-remove
+++ /dev/null
@@ -1,15 +0,0 @@
-#!/bin/sh -e
-# /usr/lib/emacsen-common/packages/remove/tdiary-mode
-
-FLAVOR=$1
-PACKAGE=tdiary-mode
-
-if [ ${FLAVOR} != emacs ]; then
-if test -x /usr/sbin/install-info-altdir; then
-echo remove/${PACKAGE}: removing Info links for ${FLAVOR}
-install-info-altdir --quiet --remove --dirname=${FLAVOR} 
/usr/info/tdiary-mode.info.gz
-fi
-
-echo remove/${PACKAGE}: purging byte-compiled files for ${FLAVOR}
-rm -rf /usr/share/${FLAVOR}/site-lisp/${PACKAGE}
-fi
```

Thanks,
-- 
Tatsuya Kinoshita

Bug#932944: stretch-pu: package passwordsafe/1.00+dfsg-1


On 2019-07-26 20:40, Bill Blough wrote:

For reference, the buster-pu request is 932945.


Thanks. I didn't spot that originally because it was missing the user 
for the usertag, so had associated it with your user instead. I've now 
added a tag for our user as well.


Regards,

Adam

Bug#933150: evolution crashes on loading external contents

2019-07-26 Thread Alf Gaida

Package: evolution
Version: 3.32.2-1
Severity: grave

Same bug for evolution/unstable when loading ext content in several html mails 
- if you cant reproduce i could forward such a mail.

Thread 83 "pool-evolution" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcef2b700 (LWP 1891)]
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:132
132 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: Datei oder Verzeichnis 
nicht gefunden.
(gdb) bt
#0  0x743e1a30 in __memcpy_ssse3 () at 
../sysdeps/x86_64/multiarch/memcpy-ssse3.S:132
#1  0x772c358a in g_memdup () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x73764d0b in soup_buffer_new () at 
/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#3  0x73764d73 in soup_buffer_copy () at 
/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#4  0x73765004 in soup_message_body_append_buffer () at 
/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#5  0x73767da1 in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#6  0x737683d4 in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#7  0x73768e27 in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#8  0x73765915 in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#9  0x73778c4c in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#10 0x7377911e in  () at /lib/x86_64-linux-gnu/libsoup-2.4.so.1
#11 0x7fffe68d687d in  () at /usr/lib/evolution/libevolution-mail.so.0
#12 0x74565a75 in e_content_request_process_sync () at 
/usr/lib/evolution/libevolution-util.so.0
#13 0x74565cc2 in  () at /usr/lib/evolution/libevolution-util.so.0
#14 0x745dd789 in  () at /usr/lib/evolution/libevolution-util.so.0
#15 0x772cd403 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x772cccfd in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x74472fa3 in start_thread (arg=) at 
pthread_create.c:486
#18 0x743a14cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) continue
Continuing.
[1]  + 6645 suspended (tty output)  gdb evolution

Cheers Alf




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

Kernel: Linux 5.1.19-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution depends on:
ii  dbus   1.13.12-1
ii  evolution-common   3.32.2-1
ii  evolution-data-server  3.32.2-2
ii  libc6  2.28-10
ii  libcamel-1.2-623.32.2-2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-1.2-19 3.32.2-2
ii  libedataserver-1.2-24  3.32.2-2
ii  libevolution   3.32.2-1
ii  libglib2.0-0   2.61.1-2
ii  libgtk-3-0 3.24.10-1
ii  libical3   3.0.5-1
ii  libnotify4 0.7.7-4
ii  libsoup2.4-1   2.67.3-1
ii  libwebkit2gtk-4.0-37   2.24.3-1
ii  libxml22.9.8+dfsg-1+b1
ii  psmisc 23.2-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.32.2-1
ii  evolution-plugin-pstimport   3.32.2-1
ii  evolution-plugins3.32.2-1
ii  yelp 3.31.90-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.17-3
pn  network-manager 

-- no debconf information

Bug#933149: RFS: calibre/3.46.0+dfsg-1~bpo10+1

2019-07-26 Thread Nicholas D Steeves

Package: sponsorship-requests
Severity: normal

Dear mentors and Backports Team,

I am looking for a sponsor for my backport of "calibre".  I have DM
for the package and maintained the stretch backport.

Package name: calibre
Version : 3.46.0+dfsg-1~bpo10+1
URL : https://calibre-ebook.com/
License : GPL-3, and a variety of others

It builds these binary packages:

  calibre - powerful and easy to use e-book manager
  calibre-bin - powerful and easy to use e-book manager

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/calibre/calibre_3.46.0+dfsg-1~bpo10+1.dsc

Changes since the last upload (since the version in buster):

 calibre (3.46.0+dfsg-1~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.
 .
 calibre (3.46.0+dfsg-1) unstable; urgency=medium
 .
   [ Norbert Preining ]
   * Add python-html2text dependency (Closes: #932044)
   * New upstream version 3.46.0+dfsg
 .
   [ Nicholas D Steeves ]
   * Use secure URL for Homepage (d/control) & Source (d/copyright)
 .
 calibre (3.45.2+dfsg-1) unstable; urgency=medium
 .
   * New upstream version 3.45.2+dfsg
 .
 calibre (3.45.1+dfsg-1) unstable; urgency=medium
 .
   * New upstream version 3.45.1+dfsg
 .
 calibre (3.45.0+dfsg-1) unstable; urgency=medium
 .
   * New upstream version 3.45.0+dfsg
   * update patches
 .
 calibre (3.44.0+dfsg-2) unstable; urgency=medium
 .
   * Upload to unstable, use source only upload
 .
 calibre (3.44.0+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 3.44.0+dfsg
 .
 calibre (3.43.0+dfsg-1) experimental; urgency=medium
 .
* remove .pyc files on upgrade from pre-pyclean versions (Closes: #865879)
   * New upstream version 3.43.0+dfsg
   * update patches
 .
 calibre (3.42.0+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 3.42.0+dfsg
   * update patches
 .
 calibre (3.41.3+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 3.41.3+dfsg
 .
 calibre (3.41.1+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 3.41.1+dfsg
 .
 calibre (3.41.0+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 3.41.0+dfsg
   * Update and fix patches
   * add python-bs4 to build deps
   * install backports directory
 .
 calibre (3.40.1+dfsg-1) experimental; urgency=medium
 .
   * new upstream release (Closes: #924066)


Regards,
Nicholas

Bug#932944: stretch-pu: package passwordsafe/1.00+dfsg-1

2019-07-26 Thread Bill Blough



Uploaded, thanks.

For reference, the buster-pu request is 932945.

Bug#933144: shairport-sync: Daemon failed to start - shairport-sync was built without libdaemon, so does not support daemonisation using ...

2019-07-26 Thread Chris Boot

Control: severity -1 serious
Control: tag -1 confirmed

First of all, thanks very much for the clear, concise, and considered
bug report.

On 26/07/2019 18:26, Thomas wrote:
[snip]
> The shairport-sync daemon does not start.
[snip]

Ugh. How did I let that through? :-(

Really sorry about that. Thanks for the patch; it may be sufficient for
systemd but shairport-sync still needs the --daemon flag to work for
sysvinit compatibility so it's not the whole fix, sadly. I also seem to
remember having a good reason for using forking mode rather than simple
mode back when I first packaged shairport-sync, though stupidly I didn't
document why that was.

Sorry about this, will upload a fixed version as soon as I can.

Cheers,
Chris

-- 
Chris Boot
bo...@debian.org

Bug#932678: glib2.0: tests timeout on i386 and mips

2019-07-26 Thread Simon McVittie

On Fri, 26 Jul 2019 at 23:39:54 +0100, Simon McVittie wrote:
> On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote:
> > On i386, the gmenumodel test timed out.
> 
> The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which
> has a watchdog timer that is meant to kill the process with SIGALRM
> after 65 seconds, so I'm surprised it survived to 360s - either the
> watchdog timer isn't working, or multiple test-cases must have taken a
> lot longer than they are meant to.

There is some test setup that is not covered by the watchdog timer,
which has thread data races that have been fixed in upstream git master.
If this was the root cause then I'm not surprised I couldn't reproduce
the problem.

I've backported that patch in the hope that it will fix this test,
but since it's unreproducible it's hard to be sure, so I'll also skip
this test at build-time. We can revisit that change when GNOME 3.32
(or 3.34?) has landed in unstable.

smcv

Bug#932347: kalarm: Multiple akonadi_kalarm_resource processes are spawned on kalarm start and consume lot of CPU

2019-07-26 Thread David Jarvie

This seems likely to be the same bug as 
https://bugs.kde.org/show_bug.cgi?id=403124, which has now been fixed for the 
KDE Applications 19.08 release. The fix is to remove any duplicate Akonadi 
resources (i.e. which use the same calendar file) at KAlarm startup. The user 
is also now prevented from manually creating duplicate resources via KAlarm's 
interface.

See the KDE bug report for details of the git commits which fix this issue.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

Bug#932866: RFS: elpy/1.29.1+40.gb929013-1 -- Emacs Python Development Environment

2019-07-26 Thread Nicholas D Steeves

Hi Chris,

On Thu, Jul 25, 2019 at 11:59:58PM -0300, Chris Lamb wrote:
> tags 932866 + pending
> thanks
> 
> Hi Nicholas,
> 
> > I tagged a new upstream snapshot which included my spelling fix, and
> > defends against broken tests that upcoming parso/jedi updates will
> > cause (78aea0e).
> 
> Neat; uploaded.
>

Thank you!

> > The new grammar and spelling errors will be resolved in the next
> > Debian upload based off of a stable upstream release.
> 
> Sure thing. Would seem a poor use of one's efforts to patch these
> locally, after all...
> 

Indeed ;-)  Thank you for your understanding.

Have a great day!
Nicholas


signature.asc
Description: PGP signature

Bug#932678: glib2.0: tests timeout on i386 and mips

2019-07-26 Thread Simon McVittie

On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote:
> On i386, the gmenumodel test timed out.

I can't reproduce this locally, and it normally takes about 6-7 seconds
on an i386 VM on my laptop. It has had issues with arbitrary delays in
the past, and got moved to the "slow" test suite because it was sometimes
taking more than 60s in upstream's CI, so I'm quite prepared to believe
that there is some intermittent problem.

The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which
has a watchdog timer that is meant to kill the process with SIGALRM
after 65 seconds, so I'm surprised it survived to 360s - either the
watchdog timer isn't working, or multiple test-cases must have taken a
lot longer than they are meant to.

If I can't reproduce this well enough to debug it, the best I'll be able
to do is to disable this particular test at build-time.

> On mips, the gvariant test timed out.

This is failing a fuzz-test that randomly modifies binary data and
tries to parse it. I thought it might be reaching some pathological
case where the parser breaks, but no - it looks like the actual problem
is that g_random_double_range() is really slow on at least some mips
hardware (repeatedly calling g_random_double_range() in a loop is 100
times as fast on my laptop as on the porterbox minkus, which according
to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01,
the buildd where this test timed out).

mips porters: Is this something that is expected to be so slow? The
same test took 60 seconds (so at least 6 times as fast) on mips-sil-01,
which is apparently a Rhino Labs UTM8 with a somewhat newer CPU.
For comparison, it took 8 seconds on the i386 buildd.

There probably isn't much point in trying very hard to run this test on
mips, so I'll disable this one as a build-time test too.

smcv

Bug#933148: lxqt: multiple Desktops with Cinnamon and LXQt don't work

2019-07-26 Thread Christian

Package: lxqt
Version: 29
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I want to have more than one tesktop to evaluate which fits best to my needs.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
During installation of Buster I installed Cinnamon desktop only.
Afterwards I added LXQt desktop.

   * What was the outcome of this action?
I am configuring the desktop LXQt and choose element "network" to be shown. But
it isn't shown on the desktop. When I switch to desktop Cinnamon again this
element is shown on desktop Cinnamon!

   * What outcome did you expect instead?
I expect the elements shown on the right desktop.




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

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

Versions of packages lxqt depends on:
ii  cinnamon [x-window-manager]   3.8.8-1
ii  featherpad0.9.4-2
ii  lightdm   1.26.0-4
ii  lximage-qt0.14.1-1
ii  lxqt-about0.14.1-1
ii  lxqt-admin0.14.1-1
ii  lxqt-branding-debian [lxqt-branding]  0.14.0.3
ii  lxqt-core 29
ii  lxqt-openssh-askpass  0.14.1-1
ii  lxqt-powermanagement  0.14.1-1
ii  lxqt-sudo 0.14.1-2
ii  muffin [x-window-manager] 3.8.2-1
ii  pavucontrol-qt0.14.1-1
ii  qlipper   1:5.1.2-1
ii  qps   1.10.20-1
ii  qterminal 0.14.1-1
ii  qttranslations5-l10n  5.11.3-2
ii  xarchiver 1:0.5.4.14-1
ii  xfwm4 [x-window-manager]  4.12.5-1

Versions of packages lxqt recommends:
ii  audacious   3.10.1-1
ii  feathernotes0.4.6-1
ii  firefox-esr [www-browser]   60.8.0esr-1~deb10u1
ii  gucharmap   1:11.0.3-3
ii  hexchat 2.14.2-4
ii  meteo-qt1.0.0-1
ii  network-manager-gnome   1.8.20-1.1
ii  opera-stable [www-browser]  62.0.3331.66
pn  preload 
ii  qpdfview0.4.17~beta1+git20180709-2
ii  screengrab  1.101-1
ii  smplayer18.10.0~ds0-1
ii  smtube  18.3.0-1
ii  thunderbird 1:60.8.0-1~deb10u1

Versions of packages lxqt suggests:
pn  calibre
pn  compton-conf   
pn  juffed 
pn  nomacs 
pn  obconf-qt  
pn  qt5-style-kvantum  
pn  qtpass 
pn  shutter
pn  vokoscreen 

-- no debconf information

Bug#931659: transition: rm python2

2019-07-26 Thread Jonathan Wiltshire

On Tue, Jul 23, 2019 at 12:05:07PM -0300, Stefano Rivera wrote:
> The current regex is using \bpython, which matches dh-python.
> 
> I suggest this patch, using \s instead.
> 
> Gets us down to 3455/4057.

Thanks; applied. Will take effect at the next run, I'm not inclined to make
respighi crunch that many packages right now.


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

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

Bug#933147: buster-pu: package libsdl2-image/2.0.4+dfsg1+deb10u1

2019-07-26 Thread Hugo Lefeuvre

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

libsdl2-image is currently affected by the following security issues:

* CVE-2019-5052: integer overflow and subsequent buffer overflow in
  IMG_pcx.c.

* CVE-2019-5051: heap-based buffer overflow in IMG_pcx.c.

* CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).

* CVE-2019-12216, CVE-2019-12217,
  CVE-2019-12218, CVE-2019-12219,
  CVE-2019-12220, CVE-2019-12221,
  CVE-2019-1: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).

(for more information, see #932754)

Attached is a debdiff addressing all of them for buster.

All of these patches are from upstream, I have removed whitespace changes
and non security related refactoring.

thanks!

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru libsdl2-image-2.0.4+dfsg1/debian/changelog libsdl2-image-2.0.4+dfsg1/debian/changelog
--- libsdl2-image-2.0.4+dfsg1/debian/changelog	2019-02-03 08:59:26.0 -0200
+++ libsdl2-image-2.0.4+dfsg1/debian/changelog	2019-07-26 17:01:14.0 -0300
@@ -1,3 +1,17 @@
+libsdl2-image (2.0.4+dfsg1-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Multiple security issues (Closes: #932754):
+- CVE-2019-5052: integer overflow and subsequent buffer overflow in
+  IMG_pcx.c.
+- CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).
+- CVE-2019-12216, CVE-2019-12217,
+  CVE-2019-12218, CVE-2019-12219,
+  CVE-2019-12220, CVE-2019-12221,
+  CVE-2019-1, CVE-2019-5051: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).
+
+ -- Hugo Lefeuvre   Fri, 26 Jul 2019 17:01:14 -0300
+
 libsdl2-image (2.0.4+dfsg1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch
--- libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch	1969-12-31 21:00:00.0 -0300
+++ libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch	2019-07-26 17:01:14.0 -0300
@@ -0,0 +1,84 @@
+Description: fix heap buffer overflow issue in IMG_pcx.c
+ Issue known as TALOS-2019-0841, CVE-2019-12218.
+Author: Sam Lantinga 
+Origin: upstream, https://hg.libsdl.org/SDL_image/rev/7453e79c8cdb
+--- a/IMG_pcx.c	2019-07-26 17:35:40.331470589 -0300
 b/IMG_pcx.c	2019-07-26 17:48:45.760965290 -0300
+@@ -98,6 +98,8 @@
+ Uint8 *row, *buf = NULL;
+ char *error = NULL;
+ int bits, src_bits;
++int count = 0;
++Uint8 ch;
+ 
+ if ( !src ) {
+ /* The error message has been set in SDL_RWFromFile */
+@@ -146,14 +148,14 @@
+ bpl = pcxh.NPlanes * pcxh.BytesPerLine;
+ if (bpl > surface->pitch) {
+ error = "bytes per line is too large (corrupt?)";
++goto done;
+ }
+-buf = (Uint8 *)SDL_calloc(SDL_max(bpl, surface->pitch), 1);
++buf = (Uint8 *)SDL_calloc(surface->pitch, 1);
+ row = (Uint8 *)surface->pixels;
+ for ( y=0; yh; ++y ) {
+ /* decode a scan line to a temporary buffer first */
+-int i, count = 0;
+-Uint8 ch;
+-Uint8 *dst = (src_bits == 8) ? row : buf;
++int i;
++Uint8 *dst = buf;
+ if ( pcxh.Encoding == 0 ) {
+ if(!SDL_RWread(src, dst, bpl, 1)) {
+ error = "file truncated";
+@@ -166,14 +168,15 @@
+ error = "file truncated";
+ goto done;
+ }
+-if( (ch & 0xc0) == 0xc0) {
+-count = ch & 0x3f;
+-if(!SDL_RWread(src, , 1, 1)) {
++if ( ch < 0xc0 ) {
++count = 1;
++} else {
++count = ch - 0xc0;
++if( !SDL_RWread(src, , 1, 1)) {
+ error = "file truncated";
+ goto done;
+ }
+-} else
+-count = 1;
++}
+ }
+ dst[i] = ch;
+ count--;
+@@ -205,10 +208,16 @@
+ int x;
+ dst = row + plane;
+ for(x = 0; x < width; x++) {
++if ( dst >= row+surface->pitch ) {
++error = "decoding out of bounds (corrupt?)";
++goto done;
++}
+ *dst = *innerSrc++;
+ dst += pcxh.NPlanes;
+ }
+ }
++} else {
++SDL_memcpy(row, buf, bpl);
+ }
+ 
+ row += surface->pitch;
+@@ -225,8 +234,9 @@
+ /* look for a 256-colour palette */
+ do {
+ if ( !SDL_RWread(src, , 1, 1)) {
+-

Bug#900349: linux-image-4.9.0-6-amd64 does not support RAID controller (530-4i Flex) of Lenovo ThinkSystem SN550 servers

2019-07-26 Thread Michael Prokop

* Michael Prokop [Wed May 30, 2018 at 10:05:16AM +0200]:
> * Ben Hutchings [Tue May 29, 2018 at 08:58:35PM +0100]:
> > On Tue, 29 May 2018 13:41:13 +0200 Michael Prokop  wrote:

> > > The current kernel version of Debian/stretch (4.9.0-6-amd64) doesn't
> > > support the RAID controller as present in Lenovo ThinkSystem SN550
> > > blade servers (https://lenovopress.com/lp0637-thinksystem-sn550-server).

[...]

> > Is it sufficient to apply that single commit?  I'm attaching a
> > slightly modified version that applies to stretch.

> Thanks for providing that patch, sadly it doesn't seem to be enough.
> `cat /proc/partitions` is empty and I'm stuck in busybox/initramfs
> during boot:

> (initramfs) dmesg | grep megaraid
> [2.735633] megaraid_sas :08:00.0: Waiting for FW to come to ready 
> state
> (initramfs) modinfo megaraid_sas | grep -i 001c
> alias:  pci:v1000d001Csv*sv*sd*bc*sc*i*

FTR, kernel v4.15 and newer support the said RAID controller,
feel free to close this bug report (not doing it myself just in case
you think it's useful to keep it open for someone else).

regards
-mika-


signature.asc
Description: Digital signature

Bug#932849: ftp.debian.org: NEW process looses .buildinfo files

2019-07-26 Thread Benjamin Hof

Hi,

I've proposed a potential fix in

https://salsa.debian.org/ftp-team/dak/merge_requests/150


Kind regards,
Benjamin

Bug#930228: partman-crypto: cryptsetup's initramfs integration was moved to a separate package

2019-07-26 Thread Guilhem Moulin

Control: severity -1 grave

Hi,

On Thu, 25 Jul 2019 at 22:31:36 +0100, Ben Hutchings wrote:
>> Thanks to the Recommends: d-i will automatically pull the initramfs
>> integration, at least on systems where APT::Install-Recommends hasn't
>> been turned off by preseeding.  (The Recommends: cryptsetup-run is there
>> to improve the upgrade path, cf. #932625.)  I'm therefore only raising
>> the severity to ‘normal’.
> 
> APT::Install-Recommends is only enabled after the base-installer phase.
> of installation.  I don't know what stage cryptsetup is installed at,
> but I suggest it's worth checking that this assumption is correct.

Thanks for the hint, ‘cryptsetup-initramfs’ is not pulled in indeed.  I
guess someone would have found out sooner or better, but the sooner the
better :-)

The attached patch fixes this.  I'll leave it to you if you want to
clone this bug and close -1, or alternatively downgrade its severity to
conditionally implement the initramfs integration:

| The real fix would be to have a detection logic triggering `apt-install
| cryptsetup` whenever there are crypt targets in the dm table, and
| `apt-install cryptsetup-initramfs` if any volume needs to be unlocked at
| initramfs stage, i.e., holding /, /usr, and/or the resume device(s).

Cheers,
-- 
Guilhem.
From b72b0934eb4c729d5fef462bb832aec6665513c8 Mon Sep 17 00:00:00 2001
From: Guilhem Moulin 
Date: Fri, 26 Jul 2019 23:24:33 +0200
Subject: [PATCH] finish.d/crypto_aptinstall: Install cryptsetup-initramfs, not
 cryptsetup.

cryptsetup's initramfs integration was moved to a separate package.
Cf. #930228.
---
 finish.d/crypto_aptinstall | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/finish.d/crypto_aptinstall b/finish.d/crypto_aptinstall
index 047d1a3..a26f5f0 100755
--- a/finish.d/crypto_aptinstall
+++ b/finish.d/crypto_aptinstall
@@ -34,6 +34,6 @@ if grep -q " device-mapper$" /proc/misc; then
 # on an LVM LV on top of an encrypted device
 if type dmsetup >/dev/null 2>&1 && \
 	   dmsetup table | cut -d' ' -f4 | grep -q "crypt" 2>/dev/null; then
-		apt-install cryptsetup || true
+		apt-install cryptsetup-initramfs || true
 	fi
 fi
-- 
2.22.0



signature.asc
Description: PGP signature

Bug#933142: /etc/init.d/cryptdisks force-start no longer ignores noauto

2019-07-26 Thread Justin Pasher

Just a quick follow-up. I found bug #505779 from 2008 where the 
force-start option was specifically added to support starting disks with 
the noauto option.


--
Justin Pasher

Bug#927313: parsinsert: probably broken on armhf, failing autopkgtests in Ubuntu

2019-07-26 Thread Steve Langasek

On Fri, Jul 26, 2019 at 10:28:31PM +0200, Andreas Tille wrote:
> Hi Steve,

> thanks a lot for this bug report.

> On Wed, Apr 17, 2019 at 04:18:30PM -0700, Steve Langasek wrote:
> > [...]

> >   
> > (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/p/parsinsert/20190206_231724_739fb@/log.gz)

> > Investigation suggests this is a regression caused by toolchain changes that
> > have resulted in a broken armhf binary build in 1.04-4: there are clearly no
> > changes to the testsuite between -3 and -4, the -3 binary still passes the
> > testsuite with current libraries, and a no-change rebuild of -3 fails the
> > same way.

> I need to admit that from a parsinerst maintainers point of view I have
> no idea what to do.

> > Since Debian does not run autopkgtests on !amd64, I would strongly recommend
> > running these tests at build time as well, to avoid shipping broken binaries
> > on other architectures.

> So your suggestion is that for future uploads we should run the test
> written in Debian as autopkgtest as a test for the upstream code.

Yes, this would catch the problem earlier and fail to build the package on
architectures where it is broken. Then you could request the old binaries be
removed from the archive.

> > Note that these tests also fail on arm64, i386, and ppc64el in Ubuntu,
> > suggestings the packages are also broken there, but none of these are
> > regressions.

> Thanks a lot for these hints

My pleasure!

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#931507: [PATCHv2] hda: Fix 1-minute detection delay when i915 module is not available

2019-07-26 Thread Samuel Thibault

Distribution installation images such as Debian include different sets
of modules which can be downloaded dynamically.  Such images may notably
include the hda sound modules but not the i915 DRM module, even if the
latter was enabled at build time, as reported on
https://bugs.debian.org/931507

In such a case hdac_i915 would be linked in and try to load the i915
module, fail since it is not there, but still wait for a whole minute
before giving up binding with it.

This fixes such as case by only waiting for the binding if the module
was properly loaded (or module support is disabled, in which case i915
is already compiled-in anyway).

Signed-off-by: Samuel Thibault 
---
 sound/hda/hdac_i915.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -136,10 +136,13 @@ int snd_hdac_i915_init(struct hdac_bus *
if (!acomp)
return -ENODEV;
if (!acomp->ops) {
-   request_module("i915");
-   /* 60s timeout */
-   wait_for_completion_timeout(_complete,
-   msecs_to_jiffies(60 * 1000));
+   if (!IS_ENABLED(CONFIG_MODULES) ||
+   !request_module("i915"))
+   {
+   /* 60s timeout */
+   wait_for_completion_timeout(_complete,
+  msecs_to_jiffies(60 * 1000));
+   }
}
if (!acomp->ops) {
dev_info(bus->dev, "couldn't bind with audio component\n");

Bug#933146: FTBFS, not Django 2.2 ready

2019-07-26 Thread Thomas Goirand

Package: python-django-rosetta
Version: 0.7.6-1
Severity: serious
Tags: patch

Hi,

Please find attached patch for the Python 2 removal part.
The package still FTBFS after this patch:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd 
/<>/.pybuild/cpython3_3.7_django-rosetta/build; python3.7 -m 
unittest discover -v 
rosetta.tests (unittest.loader._FailedTest) ... ERROR

==
ERROR: rosetta.tests (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: rosetta.tests
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/<>/.pybuild/cpython3_3.7_django-rosetta/build/rosetta/tests/__init__.py",
 line 1, in 
from .tests import *
  File 
"/<>/.pybuild/cpython3_3.7_django-rosetta/build/rosetta/tests/tests.py",
 line 3, in 
from django.contrib.auth.models import User, Group
  File "/usr/lib/python3/dist-packages/django/contrib/auth/models.py", line 2, 
in 
from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager
  File "/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line 
47, in 
class AbstractBaseUser(models.Model):
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 103, in 
__new__
app_config = apps.get_containing_app_config(module)
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 252, in 
get_containing_app_config
self.check_apps_ready()
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 134, in 
check_apps_ready
settings.INSTALLED_APPS
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 79, in 
__getattr__
self._setup(name)
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 64, in 
_setup
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, 
but settings are not configured. You must either define the environment 
variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing 
settings.


--
Ran 1 test in 0.000s

FAILED (errors=1)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.7_django-rosetta/build; python3.7 -m 
unittest discover -v 
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:10: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Build finished at 2019-07-26T21:43:50Z
diff -u -N -r debian/changelog ../debian/changelog
--- debian/changelog2019-07-26 23:44:33.561224883 +0200
+++ ../debian/changelog 2019-07-26 23:43:01.840631647 +0200
@@ -1,4 +1,4 @@
-python-django-rosetta (0.7.6-1) UNRELEASED; urgency=medium
+python-django-rosetta (0.7.6-1) unstable; urgency=medium
 
   [ Michael Fladischer ]
   * New upstream release.
@@ -24,7 +24,14 @@
   * d/watch: Use https protocol
   * Convert git repository from git-dpm to gbp layout
 
- -- Michael Fladischer   Tue, 04 Aug 2015 09:47:58 +0200
+  [ Thomas Goirand ]
+  * Team upload.
+  * Ran wrap-and-sort -bast.
+  * Switch to debhelper-compat=11.
+  * Removed Python 2 support.
+  * Add missing build-depends: python3-django, python3-polib.
+
+ -- Thomas Goirand   Fri, 26 Jul 2019 23:35:51 +0200
 
 python-django-rosetta (0.7.2-1) unstable; urgency=low
 
diff -u -N -r debian/compat ../debian/compat
--- debian/compat   2019-07-26 23:44:33.561224883 +0200
+++ ../debian/compat1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-7
diff -u -N -r debian/control ../debian/control
--- debian/control  2019-07-26 23:44:33.561224883 +0200
+++ ../debian/control   2019-07-26 23:42:33.088444857 +0200
@@ -1,50 +1,29 @@
 Source: python-django-rosetta
 Maintainer: Debian Python Modules Team 

-Uploaders: Michael Ziegler 
+Uploaders:
+ Michael Ziegler ,
 Section: python
 Priority: optional
-Build-Depends: debhelper (>= 7.0.50~),
-   dh-python,
-   python,
-   python-setuptools,
-   python3-all,
-   python3-setuptools
+Build-Depends:
+ debhelper-compat (= 11),
+ dh-python,
+ python3-all,
+ python3-django,
+ python3-polib,
+ python3-setuptools,
 Standards-Version: 3.9.6
 Vcs-Browser: https://salsa.debian.org/python-team/modules/python-django-rosetta
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-django-rosetta.git
 Homepage: http://code.google.com/p/django-rosetta
 XS-Python-Version: all
 
-Package: python-django-rosetta
-Architecture: all
-Depends: python-django,
-

Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream

intrigeri:
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-removal=debian-perl%40lists.debian.org

Scratch that (typo), it is actually:

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-perl-removal=debian-perl%40lists.debian.org

Bug#933145: libpseudo: file conflict with older pseudo

2019-07-26 Thread Simon McVittie

Package: libpseudo
Version: 1.9.0+git20190515+996bead-1
Severity: serious

> Unpacking libpseudo:amd64 (1.9.0+git20190515+996bead-1) over 
> (1.9.0+git20180920-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-hl28Fk/10-libpseudo_1.9.0+git20190515+996bead-1_amd64.deb
>  (--unpack):
>  trying to overwrite '/usr/share/man/man1/fakeroot-pseudo.1.gz', which is 
> also in package pseudo 1.9.0+git20180920-1

I think this is because the recent upload normalized the order of binary
packages in d/control:

>   * Run wrap-and-sort -bast.

but that makes debian/docs, debian/manpages, and I think also
debian/postinst and debian/prerm apply to libpseudo, not to
pseudo (because these files take effect on the first package in
d/control). Renaming these files to debian/libpseudo.docs, etc. to make
their intention more clear might help.

It would probably be a good idea for the version that fixes this to
have Breaks/Replaces on all older versions, so that upgrades from
the current version work gracefully.

Thanks,
smcv

Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream

>  - Users of Parse::DebianChangelog could list their minimal
>requirements for a new implementation.

If more folks want to play this game, we should probably move this to
a wiki page, but for the sake of getting things moving simply, here we
go:

dh-make-perl uses this module for three things:

 - t/debian-version.t: extracting the latest version of
   a changelog file

 - copyright_from_changelog:
   
- extract maintainer and date for each changelog entry

- extract content of the changelog entry, AFAICT only in order to
  detect email address changes → seems non-critical to me
  but nice to have (and I bet Lintian needs that too anyway)

pkg-perl-tools uses this module only in scripts/missing-upstream (aka.
"dpt missing-upstream"), for extracting, from each changelog entry,
the name and version of the source package.

AFAICT, all this could be reimplemented using dpkg-parsechangelog(1),
either in Parse::DebianChangelog itself or in a brand new module.

Cheers,
-- 
intrigeri

Bug#933144: shairport-sync: Daemon failed to start - shairport-sync was built without libdaemon, so does not support daemonisation using ...

2019-07-26 Thread Thomas

Package: shairport-sync
Version: 3.3.1-1
Severity: important
Tags: patch

Dear Maintainer,

I did on my testing machine my first full-upgrade after buster got
stable. I got the new shairport-sync 3.1-1 installed. Maybe something
else has changed - systemd got definitely updated too.

My problem
===
The shairport-sync daemon does not start.

I found a solution see below.

Analys

I found in
, [ /var/log/syslog ]
| Jul 26 22:23:16 osprey systemd[1]: Starting ShairportSync AirTunes receiver...
| Jul 26 22:23:16 osprey shairport-sync[2164]: shairport-sync was built without 
libdaemon, so does not support daemonisation using the -d, --d
| eamon, -j or --justDaemoniseNoPIDFile options
| Jul 26 22:23:16 osprey systemd[1]: shairport-sync.service: Can't open PID 
file /run/shairport-sync/shairport-sync.pid (yet?) after start: No
|  such file or directory
| Jul 26 22:23:16 osprey systemd[1]: shairport-sync.service: Failed with result 
'protocol'.
| Jul 26 22:23:16 osprey systemd[1]: Failed to start ShairportSync AirTunes 
receiver.
`

The package has a service file with the following line:
, [ /lib/systemd/system/shairport-sync.service ]
| ExecStart=/usr/bin/shairport-sync --daemon $DAEMON_ARGS
`

In the man page one can read:
, [ man shairport-sync ]
| --daemon Instruct  shairport-sync  to demonise itself. [...] Only
| available if shaiport-sync has been compiled with libdaemon support.
`

And in the source code file "configure.ac":
, [ https://github.com/mikebrady/shairport-sync/blob/master/configure.ac ]
| --with-libdaemon = include support for daemonising in non-systemd systems
`

My conclusion is that imho the option "--daemon" should not be in the
service file so I removed it.

Without this option the daemon starts fine but gets killed from systemd
after a minute or so. I crosschecked with the service file in the
source code
(https://github.com/mikebrady/shairport-sync/blob/master/scripts/shairport-sync.service.in)
and removed from the debian service file the line
, [ /lib/systemd/system/shairport-sync.service ]
| Type=forking
`

Solution
==
After a "systemctl daemon-reload" to reread the changed service file I
was able to start the daemon which show as "active (running)" in
systemctl status shairport-sync.

I append my patch which removes the option and the Type-line from the
service file.

Hope this helps :-).
Tom

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
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 shairport-sync depends on:
ii  adduser  3.118
ii  avahi-daemon 0.7-4+b1
ii  init-system-helpers  1.57
ii  libasound2   1.1.8-1
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libc62.28-10
ii  libconfig9   1.5-0.4
ii  libgcc1  1:9.1.0-10
ii  libpopt0 1.16-12
ii  libpulse012.2-4
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.2-3
ii  libssl1.11.1.1c-1
ii  libstdc++6   9.1.0-10

shairport-sync recommends no packages.

shairport-sync suggests no packages.

-- Configuration Files:
/etc/init.d/shairport-sync changed [not included]

-- no debconf information

-- patch 8< --
--- orig/shairport-sync.service 2019-07-17 21:14:16.0 +0200
+++ new/shairport-sync.service  2019-07-26 22:34:24.350961711 +0200
@@ -8,10 +8,9 @@
 After=avahi-daemon.service

 [Service]
-Type=forking
 Restart=on-failure
 EnvironmentFile=-/etc/default/shairport-sync
-ExecStart=/usr/bin/shairport-sync --daemon $DAEMON_ARGS
+ExecStart=/usr/bin/shairport-sync $DAEMON_ARGS
 User=shairport-sync
 Group=shairport-sync
 PIDFile=/run/shairport-sync/shairport-sync.pid
-- end patch >8 --

Bug#933143: FTBFS, not Django 2.2 ready

2019-07-26 Thread Thomas Goirand

Package: python-django-mptt
Version: 0.8.7-1
Severity: serious
Tags: patch

Hi,

Please find attached patch to do the Python 2 removal.
After this patch, your package continues to FTBFS. Please
get a fix for it.

Cheers,

Thomas Goirand (zigo)
From 373d818427a37e26e91b5e39084c634ce1d3c613 Mon Sep 17 00:00:00 2001
From: Thomas Goirand 
Date: Fri, 26 Jul 2019 23:21:21 +0200
Subject: [PATCH]   * Team upload.   * Removed Breaks+Replaces:
 python-django-mptt (<< 0.6.1-1~) after Buster release.   * Removed Python
 2 support.

---
 debian/changelog | 11 --
 debian/control   | 52 +++-
 debian/links |  1 -
 debian/rules |  2 +-
 4 files changed, 35 insertions(+), 31 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 19ded1a..9cbaf5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,15 @@
-python-django-mptt (0.8.7-2) UNRELEASED; urgency=medium
+python-django-mptt (0.8.7-2) unstable; urgency=medium
 
+  [ Ondřej Nový ]
   * Use debhelper-compat instead of debian/compat.
 
- -- Ondřej Nový   Sat, 20 Jul 2019 00:11:07 +0200
+  [ Thomas Goirand ]
+  * Team upload.
+  * Removed Breaks+Replaces: python-django-mptt (<< 0.6.1-1~) after Buster
+release.
+  * Removed Python 2 support.
+
+ -- Thomas Goirand   Fri, 26 Jul 2019 23:19:09 +0200
 
 python-django-mptt (0.8.7-1) unstable; urgency=medium
 
diff --git a/debian/control b/debian/control
index 8abd33b..aaea1a8 100644
--- a/debian/control
+++ b/debian/control
@@ -2,20 +2,25 @@ Source: python-django-mptt
 Section: python
 Priority: optional
 Maintainer: Debian Python Modules Team 

-Uploaders: Brian May 
-Build-Depends: debhelper-compat (= 9), dh-python, python3-sphinx,
- python-all (>= 2.6.6-3~), python-setuptools, python-django (>= 1.6),
- python3-all, python3-setuptools, python3-django (>= 1.6),
+Uploaders:
+ Brian May ,
+Build-Depends:
+ debhelper-compat (= 9),
+ dh-python,
+ python3-all,
+ python3-django (>= 1.6),
+ python3-setuptools,
+ python3-sphinx,
 Standards-Version: 3.9.7
 Homepage: https://github.com/django-mptt/django-mptt
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-django-mptt.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/python-django-mptt
 
-Package: python-django-mptt
+Package: python-django-mptt-doc
+Section: doc
 Architecture: all
-Suggests: python-django-mptt-doc
-Depends: ${misc:Depends}, ${python:Depends}, libjs-jquery, python-django, 
libjs-underscore
-Provides: ${python:Provides}
+Depends:
+ ${misc:Depends},
 Description: Modified Preorder Tree Traversal Django application
  Django MPTT is a reusable/standalone Django application which aims to
  make it easy for you to use Modified Preorder Tree Traversal with your
@@ -23,26 +28,21 @@ Description: Modified Preorder Tree Traversal Django 
application
  .
  It takes care of the details of managing a database table as a tree
  structure and provides tools for working with trees of model instances.
-
-Package: python3-django-mptt
-Architecture: all
-Suggests: python-django-mptt-doc
-Depends: ${misc:Depends}, ${python3:Depends}, libjs-jquery, python3-django, 
libjs-underscore
-Provides: ${python3:Provides}
-Description: Modified Preorder Tree Traversal Django application
- Django MPTT is a reusable/standalone Django application which aims to
- make it easy for you to use Modified Preorder Tree Traversal with your
- own Django models in your own applications.
  .
- It takes care of the details of managing a database table as a tree
- structure and provides tools for working with trees of model instances.
+ This package contains the documentation.
 
-Package: python-django-mptt-doc
-Section: doc
+Package: python3-django-mptt
 Architecture: all
-Depends: ${misc:Depends}
-Breaks: python-django-mptt (<< 0.6.1-1~)
-Replaces: python-django-mptt (<< 0.6.1-1~)
+Suggests:
+ python-django-mptt-doc,
+Depends:
+ libjs-jquery,
+ libjs-underscore,
+ python3-django,
+ ${misc:Depends},
+ ${python3:Depends},
+Provides:
+ ${python3:Provides},
 Description: Modified Preorder Tree Traversal Django application
  Django MPTT is a reusable/standalone Django application which aims to
  make it easy for you to use Modified Preorder Tree Traversal with your
@@ -50,5 +50,3 @@ Description: Modified Preorder Tree Traversal Django 
application
  .
  It takes care of the details of managing a database table as a tree
  structure and provides tools for working with trees of model instances.
- .
- This package contains the documentation.
diff --git a/debian/links b/debian/links
index bf454c2..ab7e0de 100644
--- a/debian/links
+++ b/debian/links
@@ -1,3 +1,2 @@
 /usr/share/javascript/jquery/jquery.js 
usr/share/doc/python-django-mptt/html/static/jquery.js
 /usr/share/javascript/underscore/underscore.js 
usr/share/doc/python-django-mptt/html/static/underscore.js
-
diff --git a/debian/rules b/debian/rules
index 97b51ee..f7154df 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export

Bug#932570: dgit should pin to the LE CA for ftpmasterapi

2019-07-26 Thread Ian Jackson

For now, I wanted to document my progress so far.

I have a branch which contains an test which runs a mockup http server
(thanks to intrigeri for recommendations etc.) and runs an
ftpmasterapi command against it to check things are working.

The work which remains to be done is:
 1. Write test case shell code to generate a mockup of the
 current and future LE situations
 2. Convert the test case to TLS
 3. Implement code in dgit to support cert pinning
 4. Add the cert pinning to the test case config
 5. Add appropriate failure cases (t-expect-fail)

For 2 and 3 we have helpful runes from intrigeri, I think.  I'm
finding 1 a bit of a struggle.

My current WIP branch (rebasing) is here:
  https://salsa.debian.org/dgit-team/dgit/commits/wip.tls

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#919641: transition: readline (7 -> 8)

2019-07-26 Thread Matthias Klose

On 26.07.19 20:17, Jonathan Wiltshire wrote:
> Control: tag -1 pending
> 
> On Fri, Jan 18, 2019 at 08:45:38AM +0100, Matthias Klose wrote:
>> readline is in experimental for some time, the changes are API compatible, 
>> and
>> afaics there are no build failures caused by readline. I filed some RC issues
>> for unrelated ftbfs.
>>
>> A handful of packages need sourceful uploads, like d-shlibs and 
>> readline-perl6.
> 
> I think all feasible rebuilds are done or look like they will succeed;
> we're left with:
> 
> argus-clients
> bareos
> iverilog
> libvirt
> monero
> sagemath
> yap
> 
> Can I leave bugs for those with you?

I checked that any of these ftbfs for different reasons, and filed RC issues for
those that didn't already have RC reports.

Bug#933142: /etc/init.d/cryptdisks force-start no longer ignores noauto

2019-07-26 Thread Justin Pasher


Package: cryptsetup
Version: 2:2.1.0-5

Upon upgrading from Stretch to Buster, I've noticed that the SysV init 
script for starting LUKS encrypted partitions (/etc/init.d/cryptdisks) 
can no longer be forced to start disks that have the "noauto" option 
set, even when using the force-start command. I'm using sysvinit-core 
and not systemd.


For example, /etc/crypttab has this:
encdata    /dev/xvdb    none    luks,noearly,noauto

I'm purposely using the noauto option to keep the boot up process from 
automatically trying to unlock the partition and waiting for a password. 
In Stretch, if I manually run "/etc/init.d/cryptdisks force-start", it 
would bypass the noauto option and (as the command implies) force 
cryptsetup to attempt to unlock the partition. In Buster, when using the 
force-start option, it won't attempt to unlock the partition if it has 
the noauto option set.


I've looked at the two key files used by the init script 
(/lib/cryptsetup/cryptdisks-functions and /lib/cryptsetup/functions), 
and based upon what I can see, the FORCE_START option that's set by the 
init script basically becomes useless with the way the logic is 
currently defined. The only thing it seems to do is decide whether the 
word "ignored" is displayed; it doesn't change the logic flow. The lines 
in question are below (I included the logic for the noearly, since it 
suffers the same problem):


--
if [ -n "${CRYPTTAB_OPTION_noearly+x}" ] && [ "$INITSTATE" = "early" ]; then
    [ -z "${FORCE_START-}" ] || device_msg "ignored"
    return 0
fi
if [ -n "${CRYPTTAB_OPTION_noauto+x}" ] && [ "$INITSTATE" != "manual" ]; 
then

    [ -z "${FORCE_START-}" ] || device_msg "ignored"
    return 0
fi
--

These are the only code blocks that reference FORCE_START, and as you 
can see, all it does is change the displayed message. Unless I'm missing 
something, how it decides to display the message seems backwards to me 
too (it does "show this message when FORCE_START is set", versus "show 
this message when the script is executed normally and we find noauto or 
noearly").


When trying to understand how $INITSTATE is ever anything but "early" or 
"remaining" (as set by the init scripts), I found the 
/sbin/cryptdisks_start script. Running that script allows you to unlock 
a specific encrypted partition, but not all (without some manual 
scripting to read through /etc/crypttab).


Basically, I see two possible solutions:

* Running "/etc/init.d/cryptstart force-start" should ALWAYS try to 
unlock a partition, even if it has noearly or noauto set (like it did in 
Stretch).
* /sbin/cryptdisks_start must be used when trying to unlock partitions 
that use noauto or noearly and I have to write a script to loop through 
all encrypted partitions to pass as a parameter.


The first option seems most logical to me, as that's what "force-start" 
means to me. That's the way it worked in Stretch (and maybe even 
Jessie). Otherwise, what's the point of having force-start?


--
Justin Pasher

Bug#933141: RM: acoustid-fingerprinter -- RoQA; Orphaned; Upstream Inactive; Affected by Qt4 Removal

2019-07-26 Thread Boyuan Yang

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

Package acoustid-fingerprinter [1] has been orphaned since 2016 and that its
upstream has been inactive since 2016. Besides, it is currently using Qt4,
which is projected to be removed from Debian archive. Its popcon is also
rather low (< 100).

As a result, please consider removing this package. Thanks!

Regards,
Boyuan Yang

[1] https://tracker.debian.org/pkg/acoustid-fingerprinter

Bug#933140: patch: Temporary file leaked on failed ed-style patch

2019-07-26 Thread Salvatore Bonaccorso

Source: patch
Version: 2.7.6-2
Severity: normal
Tags: upstream
Forwarded: https://savannah.gnu.org/bugs/?53820
Control: found -1 2.7.5-1+deb9u1
Control: found -1 2.7.6-3
Control: found -1 2.7.6-5


Hi

The bugfix for CVE-2018-1000156 did introduce a file leak when
applying ed-style patches. This was reported in SuSE as [1] and
upstream at [2]. There are two followup commits needed to address the
issue [3] and [4].

Regards,
Salvatore

 [1] https://bugzilla.suse.com/show_bug.cgi?id=1092500
 [2] https://savannah.gnu.org/bugs/?53820
 [3] 
http://git.savannah.gnu.org/cgit/patch.git/commit/?id=19599883ffb6a450d2884f081f8ecf68edbed7ee
 [4] 
http://git.savannah.gnu.org/cgit/patch.git/commit/?id=369dcccdfa6336e5a873d6d63705cfbe04c55727

Bug#933139: bind9 fails on startup: can't find /var/cache/bind

2019-07-26 Thread Ross Boylan

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1
Severity: normal

Dear Maintainer,

Severity is import for me, but obviously this isn't happening to
everyone.  Every time I start bind9 fails, and all the other startup
services that require working DNS end up in various semi-broken
states. I can fix this after the system is up.

* What led up to the situation?

   Start or restart the system.  bind9 attempts to start, but fails
   with the error that it is unable to cd to /var/cache/bind.  This
   happens every time.

   New installation of buster with existing customizations from an old
   system ported over, with adoptions.

   resolvconf in use.

   /var is a separate partition.  See details below for my theory the
   failure arises from a race condition in which bind starts before
   /var is mounted.

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

   1. ; I have added /etc/systemd/system/bind9.service.d/override.conf with
   [Unit]
   RequiresMountsFor=/var
   
   but it didn't help.

   2. *After* the system has started I can start bind successfully.
   Then I need to restart other services that were messed up by lack
   of DNS.

   3. Reviewed and maybe added some entries to the apparmor profile.
   This helped with some of my customizations, but a simple apparmor
   problem would not block initial access to a directory and then
   permit later access.

   4. Discuss on debian-user.

* What outcome did you expect instead?
   I expected bind would start the first time.

* Details

The root partition includes /var/cache, but no /var/cache/bind.
When the partition with /var is mounted it has a /var/cache/bind
directory.

So it seems most likely the initial startup is happening before /var
is mounted, and fails when it can't find /var/cache/bind, while the
later startups happen after /var is mounted and so succeed.

The default systemd is controlling startup.

I'm not sure what I need to do to express this dependency properly;
either my RequireMountsFor does not have the effects my reading of the
documentation suggests it should, or my override is not actually
taking effect.

/var is encrypted on top of lvm, so it takes a bunch of steps to mount
it.  However, it does not require me to enter any new passwords to
decrypt it.  The root partition does require me to enter a password,
which happens early in startup.

/etc/systemd/system/bind9.service.wants/bind9-resolvconf.service is a
symlink to /lib/systemd/system/bind9-resolvconf.service.  I believe it
is present because I deliberately activated it.  This might be
inconsistent with the debconf run-resolvconf setting (of false).

I'm master for my local domain with files in /var/lib/bind; I have
inside and outside views.

I'm using /run/named/named.resolvers as suggested by this package (at
least in earlier versions) and scripts based on those previously
distributed with this package.

Logs:
-- Logs begin at Sat 2019-05-11 16:11:40 PDT, end at Sat 2019-05-11 17:08:02 
PDT. --
May 11 16:11:42 barley named[609]: linked to libjson-c version: 0.12.1
May 11 16:11:42 barley named[609]: threads support is enabled
May 11 16:11:42 barley named[609]: 

May 11 16:11:42 barley named[609]: BIND 9 is maintained by Internet Systems 
Consortium,
May 11 16:11:42 barley named[609]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit
May 11 16:11:42 barley named[609]: corporation.  Support and training for BIND 
9 are
May 11 16:11:42 barley named[609]: available at https://www.isc.org/support
May 11 16:11:42 barley named[609]: 

May 11 16:11:42 barley named[609]: adjusted limit on open files from 524288 to 
1048576
May 11 16:11:42 barley named[609]: found 8 CPUs, using 8 worker threads
May 11 16:11:42 barley named[609]: using 7 UDP listeners per interface
May 11 16:11:42 barley named[609]: using up to 4096 sockets
May 11 16:11:44 barley named[609]: loading configuration from 
'/etc/bind/named.conf'
May 11 16:11:44 barley named[609]: /etc/bind/named.conf.options:2: change 
directory to '/var/cache/bind' failed: file not found
May 11 16:11:44 barley named[609]: /etc/bind/named.conf.options:2: parsing 
failed: file not found
May 11 16:11:44 barley named[609]: loading configuration: file not found
May 11 16:11:44 barley named[609]: exiting (due to fatal error)


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

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_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9utils 1:9.11.5.P4+dfsg-5.1
ii  debconf

Bug#932847: libbinutils: Can no longer link to Qt provided amd64 libraries - "error adding symbols: bad value"

2019-07-26 Thread Pierre

On Friday, July 26, 2019 3:00:40 PM CEST Matthias Klose wrote:
> On 25.07.19 23:36, Pierre wrote:
> > On Thursday, July 25, 2019 11:19:37 PM CEST you wrote:
> >> Control: tags -1 + moreinfo
> >> 
> >> On 23.07.19 22:35, Pierre Ducroquet wrote:
> >>> Package: libbinutils
> >>> Version: 2.32.51.20190707-1
> >>> Severity: important
> >>> 
> >>> Dear Maintainer,
> >>> 
> >>> After upgrading from 2.31.1-16 to 2.32.51.20190707-1, linking to Qt-
> > 
> > provided QtWebEngine fails with the following error:
>  g++- -Wl,-rpath,/home/snoopy/Qt/5.12.3/gcc_64/lib
>  -Wl,-rpath-link,/home/snoopy/Qt/5.12.3/gcc_64/lib  -o my-app *.o
>  -L/usr/lib/ -l:libstlink.so.1 -lusb-1.0
>  -L/home/snoopy/Qt/5.12.3/gcc_64/lib -lQt5QuickControls2 -lQt5WebEngine
>  -lQt5WebEngineCore -lQt5Quick -lQt5Gui -lQt5WebChannel -lQt5Qml
>  -lQt5Network -lQt5Positioning -lQt5Test -lQt5Sql -lQt5SerialPort
>  -lQt5Core -lGL -lpthread>
> >>> 
> >>> /usr/bin/ld: /home/snoopy/Qt/5.12.3/gcc_64/lib/libQt5WebEngineCore.so:
> >>> error adding symbols: bad value
> >> 
> >> please could you provide the object files used for that link, or tell me
> >> which package you are trying to build?
> > 
> > Hello
> > 
> > The whole procedure to reproduce is as follow (with the Qt-provided
> > 'official'
> > 5.12.3 amd64 build from www.qt.io installed in ~/Qt/5.12.3):
> ok, so this is not seen with any Debian package?  In this case, please
> provide *all* object files and libraries needed for the link.

Hi

I've built a small archive with all the files needed. Sorry it's still a bit 
heavy after compression, but it's WebEngine…
http://host.pinaraf.info/~pinaraf/demo-link-fail.tar.xz
I've included a fail-link.sh demo script that shows the problem.

Regards

 Pierre


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

Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd

2019-07-26 Thread Philipp Huebner

> I built erlang-p1-tls 1.1.1 but
> didn't have any luck with the issue at hand, so I reverted to the buster
> released versions.  Perhaps it's worth another try with the newer
> erlang-p1-tls package and looking at this certificate issue?

The certificate handling is done by the erlang-p1-pkix package.
You can try updating both if you like.



signature.asc
Description: OpenPGP digital signature

Bug#933130: FTBFS, not Django 2.2 ready

2019-07-26 Thread Thomas Goirand

Package: python3-django-debug-toolbar
Version: 1:1.9.1-1
Severity: serious
Tags: patch

Hi,

Please find attached to this bug report, a patch to remove Python2 support in
your package.

Since Django 2.2 was uploaded to Sid (with Py2 removal), your package can't
build. After applying the attached patch, I get this, which shows missing Django
2.2 compatibility.

FYI, I know how to fix the MIDDLEWARE issue (I did fix similar issues in other
packages), but I don't know about the other errors.

dh_auto_test
I: pybuild base:217: PYTHONPATH=. DJANGO_SETTINGS_MODULE=tests.settings 
django-admin test tests
Creating test database for alias 'default'...
..s...EEEF......
==
ERROR: test_check_good_configuration 
(tests.test_integration.DebugToolbarSystemChecksTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 373, in inner
return func(*args, **kwargs)
  File "/<>/tests/test_integration.py", line 339, in 
test_check_good_configuration
messages = run_checks()
  File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 
72, in run_checks
new_errors = check(app_configs=app_configs)
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
111, in check_dependencies
if not 
_contains_subclass('django.contrib.auth.middleware.AuthenticationMiddleware', 
settings.MIDDLEWARE):
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
41, in _contains_subclass
for path in candidate_paths:
TypeError: 'NoneType' object is not iterable

==
ERROR: test_check_gzip_middleware_error 
(tests.test_integration.DebugToolbarSystemChecksTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 373, in inner
return func(*args, **kwargs)
  File "/<>/tests/test_integration.py", line 365, in 
test_check_gzip_middleware_error
messages = run_checks()
  File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 
72, in run_checks
new_errors = check(app_configs=app_configs)
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
111, in check_dependencies
if not 
_contains_subclass('django.contrib.auth.middleware.AuthenticationMiddleware', 
settings.MIDDLEWARE):
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
41, in _contains_subclass
for path in candidate_paths:
TypeError: 'NoneType' object is not iterable

==
ERROR: test_check_missing_middleware_error 
(tests.test_integration.DebugToolbarSystemChecksTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 373, in inner
return func(*args, **kwargs)
  File "/<>/tests/test_integration.py", line 344, in 
test_check_missing_middleware_error
messages = run_checks()
  File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 
72, in run_checks
new_errors = check(app_configs=app_configs)
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
111, in check_dependencies
if not 
_contains_subclass('django.contrib.auth.middleware.AuthenticationMiddleware', 
settings.MIDDLEWARE):
  File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 
41, in _contains_subclass
for path in candidate_paths:
TypeError: 'NoneType' object is not iterable

==
FAIL: test_middleware_factory_functions_supported 
(tests.test_integration.DebugToolbarSystemChecksTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 373, in inner
return func(*args, **kwargs)
  File "/<>/tests/test_integration.py", line 391, in 
test_middleware_factory_functions_supported
self.assertEqual(messages, [])
AssertionError: Lists differ: [

+ []
- [,
-  ,
-  ]

--
Ran 76 tests in 0.554s

FAILED (failures=1, errors=3, skipped=5)
Destroying test database for alias 'default'...
System check identified no issues (0 silenced).
E: pybuild pybuild:341: test: plugin custom failed with: exit code=1: 
PYTHONPATH=. DJANGO_SETTINGS_MODULE=tests.settings django-admin test tests
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make[1]: *** [debian/rules:13: override_dh_auto_test] Error 255
make[1]:

Bug#933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client

2019-07-26 Thread Vincent Lefevre

Package: apache2
Version: 2.4.25-3+deb9u7
Severity: important

I sometimes get SEC_ERROR_OCSP_TRY_SERVER_LATER errors in Firefox
when I connect to my web server. The apache log shows errors like

[Fri Jul 26 20:01:31.355081 2019] [ssl:error] [pid 13552:tid 139871725876992] 
[client 207.46.13.73:1928] AH02321: empty response from OCSP server
[Fri Jul 26 20:01:31.366890 2019] [ssl:error] [pid 13552:tid 139871725876992] 
[client 207.46.13.73:1928] AH01980: bad response from OCSP server: (none)
[Fri Jul 26 20:01:31.366961 2019] [ssl:error] [pid 13552:tid 139871725876992] 
AH01941: stapling_renew_response: responder error

I am not the only one getting such an issue. See:

  https://lafibre.info/cryptographie/ocsp-stapling-lets-encrypt/
  
https://community.letsencrypt.org/t/ocsp-error-is-taking-down-my-site-in-firefox/19496/4
  
https://www.reddit.com/r/sysadmin/comments/bh85ze/sectigos_ocsp_stapling_issues_earlier_this_week/

I think that a way to solve this issue is to add another option
specifying how long a cached response remains valid in case of error
(as long as it satisfies the SSLStaplingResponseMaxAge condition).

-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.25-3+deb9u7
ii  apache2-data 2.4.25-3+deb9u7
ii  apache2-utils2.4.25-3+deb9u7
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  perl 5.24.1-3+deb9u5
ii  procps   2:3.3.12-3+deb9u1

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.39

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.8.9dev11-1

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.2-5
ii  libaprutil1  1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap 1.5.4-3
ii  libc62.24-11+deb9u4
ii  libldap-2.4-22.4.44+dfsg-5+deb9u2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libnghttp2-141.18.1-1
ii  libpcre3 2:8.39-3
ii  libssl1.0.2  1.0.2s-1~deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  perl 5.24.1-3+deb9u5
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.8.9dev11-1

Versions of packages apache2 is related to:
ii  apache2  2.4.25-3+deb9u7
ii  apache2-bin  2.4.25-3+deb9u7

-- Configuration Files:
/etc/apache2/envvars changed:
unset HOME
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
else
SUFFIX=
fi
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
export LANG=C
export LANG
export MY_IPS="127 ::1/128 155.133.131.76 2001:4b99:1:3:216:3eff:fe20:ac98 
86.75.119.128 2a02:8429:80cd:3100::/56 80.65.226.245"

/etc/apache2/mods-available/ssl.conf changed:

# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512
##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##
#
#   Some MIME-types for downloading Certificates and CRLs
#
AddType

Bug#931548: Migration to Sphinx

2019-07-26 Thread Holger Levsen

hi,

On Thu, Jul 25, 2019 at 10:22:24PM +0900, Osamu Aoki wrote:
> > > -- I'm afraid I wasn't involved other than reporting problems with the
> > > published version of Policy, and I don't think we made changes to our
> > > package in response to any requests from the www-team.
> > Am I correct to assume we could go a similar way with 
> > src:developers-reference ?
> Yes.

coolio

> Only remaining problem is it builds multi-language outputs as packages
> but not for web.

well, the packaging also expects to have .txt files to work on to
replace the placeholders with common-entities?


> I mean that the English files are available on
> www.debian.org but translations don't show up as described in
> https://www.debian.org/intro/cn This is because  all html files are
> names as index.html etc. without language code, so automatic language
> selection can not be implemented.
> 
> We can do 2 ways.  
[...] 
> If I figure how to set up option2 type i18n web page, I may even do it
> for debian-handbook.

yeah, I also strongly prefer option 2.


-- 
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#927313: parsinsert: probably broken on armhf, failing autopkgtests in Ubuntu

2019-07-26 Thread Andreas Tille

Hi Steve,

thanks a lot for this bug report.

On Wed, Apr 17, 2019 at 04:18:30PM -0700, Steve Langasek wrote:
> [...]
> 
>   
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/p/parsinsert/20190206_231724_739fb@/log.gz)
> 
> Investigation suggests this is a regression caused by toolchain changes that
> have resulted in a broken armhf binary build in 1.04-4: there are clearly no
> changes to the testsuite between -3 and -4, the -3 binary still passes the
> testsuite with current libraries, and a no-change rebuild of -3 fails the
> same way.

I need to admit that from a parsinerst maintainers point of view I have
no idea what to do.

> Since Debian does not run autopkgtests on !amd64, I would strongly recommend
> running these tests at build time as well, to avoid shipping broken binaries
> on other architectures.

So your suggestion is that for future uploads we should run the test
written in Debian as autopkgtest as a test for the upstream code.
 
> Note that these tests also fail on arm64, i386, and ppc64el in Ubuntu,
> suggestings the packages are also broken there, but none of these are
> regressions.

Thanks a lot for these hints

  Andreas.

-- 
http://fam-tille.de

Bug#933102: astropy breaks multiple autopkgtest (uncoordinated transition or unintended drop of files?)

2019-07-26 Thread Paul Gevers

Hi,

On 26-07-2019 20:18, Paul Gevers wrote:
> If all this is intended, I failed to spot the coordination
> with the reverse dependencies (the first three packages I checked didn't
> have any bug at all).

It seems I should have searched longer. I spotted multiple bug reports
now, so sorry for the noise. Feel free to close this bug if everything
is under control.

Paul

signature.asc
Description: OpenPGP digital signature

Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream

Package: libparse-debianchangelog-perl
Version: 1.2.0-13
Severity: serious

Hi,

many years ago, the Debian Perl group has unwillingly inherited the
role of de facto upstream maintainer for this package: all changes
done since 2011 were applied as Debian patches. We don't feel we're in
a good position to wear the upstream hat here and would rather not to.

Therefore, at the pkg-perl BoF today at DebConf, after pondering other
options such as orphaning this package, we decided that we don't want
this package to be included in Bullseye (at least, maintained under
the Perl team umbrella) unless someone else steps up and becomes its
upstream maintainer. Hence, we're filing this RC bug to alert about
this situation. I'll also file bugs against all reverse-dependencies,
pointing to this discussion.

libparse-debianchangelog-perl has quite a few reverse-dependencies,
some of them critical to Debian (such as Lintian) or to our own team
(dh-make-perl, pkg-perl-tools) so let's hope that something good comes
out of this currently unsustainable situation. For example:

 - Users of Parse::DebianChangelog could list their minimal
   requirements for a new implementation.

   This could be useful in case someone is ready to write and maintain
   something like this, but does not want to maintain the current
   codebase and its full API.

 - Someone takes over Parse::DebianChangelog and becomes the
   new upstream.

 - 

Note that libparse-debianchangelog-perl is on the list of key
packages¹ so this RC bug won't trigger the autoremoval machinery for
it, nor for any of its reverse dependencies.

[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Cheers,
-- 
intrigeri

Bug#933040: ejabberd: certificates created with GnuTLS no longer compatible with ejabberd

2019-07-26 Thread Philipp Huebner

Hi again!


Am 26.07.19 um 20:17 schrieb Gerald Turner:
> On Fri, Jul 26 2019, Philipp Huebner wrote:
>
>> I have contacted upstream, and they requested sample certificates
>> (PEMs) for ejabberd (cert+key) and CA (without key).
> 
> Great!  Did they really want the host key PEM file?

Yes they did, probably to be able to debug a running ejabberd.


> On a random machine running Debian buster that hadn't been running
> ejabberd before, I've been able to reproduce this bug with the following
> steps:

[...]

Thx again, that's very helpful!


> Thanks.  I do not have a GH account and would appreciate this very much.

Done: https://github.com/processone/pkix/issues/2


Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#930420: stretch-pu: package grub2/2.02~beta3-5+deb9u2


Control: tags -1 + confirmed d-i

On 2019-06-12 08:29, Colin Watson wrote:

I'd like to upload an update to stretch's grub2 which adds support for
booting Xen on UEFI hosts.  This consists of four straight cherry-picks
from upstream (somewhat complex, but mostly confined to the multiboot
loader so IMO low-risk for other boot methods) and one cherry-pick of a
an upstream backport that I'd previously done for buster.  It was
requested by and has been tested by an upstream Xen developer.  The
proposed debdiff is attached.


Sorry for the delay in getting back to you regarding this.

While it doesn't sound like the changes should affect d-i, I would still 
appreciate an ack on that side, so tagging and CCing appropriately.


Regards,

Adam

Bug#930357: stretch-pu: package miniupnpd/1.8.20140523-4.1+deb9u2 CVE-2019-12107, CVE-2019-12108, CVE-2019-12109, CVE-2019-12110


Control: tags -1 + confirmed

On 2019-06-11 08:28, Thomas Goirand wrote:

Please allow me to upload miniupnpd/1.8.20140523-4.1+deb9u2, as the
security team told me the CVE in the Subject do not need a DSA.

The upload only adds the upstream patches, Stretch doesn't seem to
be affected by CVE-2019-12111. On top of that, the fixed version adds
a change to debian/gbp.conf (only branch names), please allow this to
get in as well, as this simplifies the packaging update tasks.


Please go ahead; thanks.

Regards,

Adam

Bug#932175: stretch-pu: package openssh/1:7.4p1-10+deb9u7


Control: tags -1 + confirmed d-i

On 2019-07-16 06:36, Moritz Muehlenhoff wrote:
This update for OpenSSH fixes a dead lock in AuthorizedKeysCommand 
(#905226).


The fixed package is running fine on a formerly affected Stretch system
(https://phabricator.wikimedia.org)


This looks OK to me, but will need a d-i ack due to the udeb; tagging 
and CCing accordingly.


Regards,

Adam

Bug#927166: libbiod0: not installable in sid

2019-07-26 Thread Andreas Tille

Hi Shayan,

On Fri, Jul 26, 2019 at 03:14:20PM +0100, Shayan Doust wrote:
> Honestly never even heard of Dlang so I thought I'd give this a try.

Let me say at first that's quite a brave approach.  I need to admit
that I als never heard before I had a package which actually needs
that library.
 
> I decided to disect and manually experiment with the Makefile to
> understand this.
> 
> The compilation stage works well, and this is failing at the linker
> stage with symbolic handling of the object files. This also tends to
> happen with poor linker parameters or just some plain misconfig. I am
> not sure what the main flag in DFLAGS does, but utilising the main flag
> on the compiler line in Makefile and not the linker line links the
> software successfully. I am not sure why a linker would need an
> extensive set of flags that is the same as the compiler.

I'f like to leave this suggestion for comments by Matthias Klumpp since
he is the D-expert and he finally helped to get the package into the
state it is now.
 
> The only fault I now see with this is that it fails at the dh_install
> stage, as the debian/tmp file for me is empty. I am not sure why and I
> am not sure what weighing that main flag had on the linker. I decided to
> manually run dub and dub test and the library unit test does run
> successfully. The generated binary in the bin file also seems to invoke
> without a complaint.
> 
> Those are my discoveries so far with something I've never touched
> before. First bug reply so I do apologise if I did violate some reply
> policy.

Totally fine for reply policy - thanks a lot for your contribution

 Andreas.

-- 
http://fam-tille.de

Bug#932944: stretch-pu: package passwordsafe/1.00+dfsg-1


Control: tags -1 + confirmed

On 2019-07-24 21:33, Bill Blough wrote:

I would like to update passwordsafe in stretch in order to fix
#932626.

As it stands, localization of the application is broken (only
English works) due to my mistake in installing the localization files
with an extra subdirectory in the path.

The only change is to move the localization files to the correct
directory, which based on the user report, and my own testing, resolves
the problem.


Please go ahead; thanks.

Please also consider fixing the issue in buster (via a separate 
release.d.o bug for that).


Regards,

Adam

Bug#931968: stretch-pu: package libtk-img/1:1.4.6+dfsg-1+deb9u1 pre-approval


Control: tags -1 + moreinfo

On 2019-07-13 01:26, Sergei Golovan wrote:

I'd like to fix #931422 (see [1]) for stretch (the bug is already fixed
in unstable, see also #931967 [2]).

The diff with the current 1:1.4.6+dfsg-1 is attaced.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931422
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931967


The same question applies here as for the buster update, i.e. what is 
the practical impact of the change?


Regards,

Adam

Bug#933126: license-reconcile: No upstream maintainer ⇒ unsuitable for Bullseye

Source: license-reconcile
Version: 0.17
Severity: serious

Hi,

many years ago, the Debian Perl group has, somewhat unwillingly,
inherited the role of upstream maintainer for this native package,
when its original author stopped taking care of it. We don't feel
we're in a good position to wear this hat and would rather not to.

Therefore, we decided at the pkg-perl BoF today at DebConf that we
don't want this package to be included in Bullseye, unless someone
else steps up and becomes its upstream maintainer.

dak tells me there's no reverse-dependency in the archive and it could
remove license-reconcile right away, but codesearch finds some
mentions of this tool in a few debian/changelog entries, so let's
first file this RC bug and let the autoremoval machinery remove the
package from testing, in the hope that someone using it takes over the
upstream maintenance job.

Cheers,
-- 
intrigeri

Bug#933127: nmu: zed_1.4-3

2019-07-26 Thread Kyle Robbertze

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

Dear release team,

It seems in the last BinNMU of zed against camomile, amd64, arm64, armhf
and i386 architectures were not rebuilt. I have tested locally and zed
rebuild successfully on amd64.

nmu zed_1.4-3 . amd64 arm64 armhf i386 . unstable . -m "rebuild against 
camomile 0.8.5-1"

Thanks

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

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

Bug#931889: Bug#933109: package-supports-alternative-init-but-no-init.d-script produces too many false positives

2019-07-26 Thread Chris Lamb

[Adding 931...@bugs.debian.org to CC for visibility]

Hi Michael,

> The underlying issue is still that this test is currently way too
> primitive and produces too many false positives to be actually useful.
> In #931889 I already listed some cases, where those false-positives are
> triggered.

Nod, and I ACK there is still further discussion to be had in
this area.

As I plan to release a new version of Lintian very soon (which will
close the "pending" #931889...) let us keep this one (ie. #933109)
open so this issue does not get lost.

Thank you for caring about Lintian. :)


Regards,

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

Bug#932030: buster-pu: package gnuplot/5.2.6+dfsg1-1+deb10u1


Control: tags -1 + confirmed

On 2019-07-14 07:07, Anton Gladky wrote:

please consider the following buster-update for the gnuplot package.
This upload fixes the issue #926658.


Please go ahead; thanks.

Regards,

Adam

Bug#933110: pkg-components: No upstream maintainer ⇒ unsuitable for Bullseye

> I'll file bugs against all reverse-dependencies to alert their
> maintainer about this situation.

Done. All such bug reports are usertagged "pkg-components-removal" so
they'll appear there shortly:

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=pkg-components-removal=debian-perl%40lists.debian.org

Cheers,
-- 
intrigeri

Bug#933125: buster-pu: package systemd/241-5+deb10u1

2019-07-26 Thread Michael Biebl

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to make a stable upload for systemd, fixing the following
issues:

systemd (241-5+deb10u1) buster; urgency=medium

  * ask-password: Prevent buffer overflow when reading from keyring.
Fixes a possible memory corruption that causes systemd-cryptsetup to
crash either when a single large password is used or when multiple
passwords have already been pushed to the keyring. (Closes: #929726)

https://salsa.debian.org/systemd-team/systemd/commit/3baec22e1fcd89a3b6d93d9a3e59bf7fa7114714

  * Clarify documentation regarding %h/%u/%U specifiers.
Make it clear, that setting "User=" has no effect on those specifiers.
Also ensure that "%h" is actually resolved to "/root" for the system
manager instance as documented in the systemd.unit man page.
(Closes: #927911)

https://salsa.debian.org/systemd-team/systemd/commit/fef3138711bd858d1718b458d257fa73317d532d

  * network: Behave more gracefully when IPv6 has been disabled.
Ignore any configured IPv6 settings when IPv6 has been disabled in the
kernel via sysctl. Instead of failing completely, continue and log a
warning instead. (Closes: #929469)

https://salsa.debian.org/systemd-team/systemd/commit/2f37176282a3f02d8839158441ba70fe3975d2b0

  * network: Fix failure to bring up interface with Linux kernel 5.2.
Backport two patches from systemd master in order to fix a bug with 5.2
kernels where the network interface fails to come up with the following
error: "enp3s0: Could not bring up interface: Invalid argument"
(Closes: #931636)

https://salsa.debian.org/systemd-team/systemd/commit/cce6b9e2c23c315659147cb28ad1a8947995a997

  * Use /usr/sbin/nologin as nologin shell.
In Debian the nologin shell is installed in /usr/sbin, not /sbin.
(Closes: #931850)

https://salsa.debian.org/systemd-team/systemd/commit/b0c697c519b731094d4ad11ae59afd76c1901aae

  [ Mert Dirik ]
  * 40-systemd: Don't fail if SysV init script uses set -u and $1 is unset
(Closes: #931719)

https://salsa.debian.org/systemd-team/systemd/commit/3f1c8e9d4c9bc5f49a13b2415f8f8845423f347f

241-5+deb10u1 is identical to 241-7 which has been uploaded to
unstable/bullseye and we haven't received any regression reports so far.

None of those changes should touch udev-udeb, i.e. d-i.
That said, I've added kibi/debian-boot to CC for his ack.

Regards,
Michael


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index ed55c95..a421cb9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+systemd (241-5+deb10u1) buster; urgency=medium
+
+  * ask-password: Prevent buffer overflow when reading from keyring.
+Fixes a possible memory corruption that causes systemd-cryptsetup to
+crash either when a single large password is used or when multiple
+passwords have already been pushed to the keyring. (Closes: #929726)
+  * Clarify documentation regarding %h/%u/%U specifiers.
+Make it clear, that setting "User=" has no effect on those specifiers.
+Also ensure that "%h" is actually resolved to "/root" for the system
+manager instance as documented in the systemd.unit man page.
+(Closes: #927911)
+  * network: Behave more gracefully when IPv6 has been disabled.
+Ignore any configured IPv6 settings when IPv6 has been disabled in the
+kernel via sysctl. Instead of failing completely, continue and log a
+warning instead. (Closes: #929469)
+  * network: Fix failure to bring up interface with Linux kernel 5.2.
+Backport two patches from systemd master in order to fix a bug with 5.2
+kernels where the network interface fails to come up with the following
+error: "enp3s0: Could not bring up interface: Invalid argument"
+(Closes: #931636)
+  * Use /usr/sbin/nologin as nologin shell.
+In Debian the nologin shell is installed in /usr/sbin, not /sbin.
+(Closes: #931850)
+
+  [ Mert Dirik ]
+  * 40-systemd: Don't fail if SysV init script uses set -u and $1 is unset
+(Closes: #931719)
+
+ -- Michael Biebl   Fri, 26 Jul 2019 21:32:04 +0200
+
 systemd (241-5) unstable; urgency=medium
 
   * Revert "Add check to switch VTs only between K_XLATE or K_UNICODE"
diff --git a/debian/extra/init-functions.d/40-systemd 
b/debian/extra/init-functions.d/40-systemd
index 4fa9b9c..e944acb 100644
--- a/debian/extra/init-functions.d/40-systemd
+++ b/debian/extra/init-functions.d/40-systemd
@@ -8,12 +8,12 @@ if [ -d /run/systemd/system ]; then

Bug#932518: buster-pu: package yubikey-personalization/1.19.3-3


Control: tags -1 + confirmed

On 2019-07-20 07:33, Nicolas Braud-Santoni wrote:

I prepared an update for buster, that:
1. fixes the stretch->buster upgrade bug (#931081) found by anbe@ ;
2. backports security fixes from upstream.

Regarding (2), upstream (Yubico) did not issue a security advisory, 
there is
no CVE or DSA assigned, and the issues aren't yet known to be 
exploitable;
as such, I believe this is suitable for -pu (as opposed to the security 
queue).


+yubikey-personalization (1.19.3-3+deb10u1) buster-proposed-updates; 
urgency=medium


Please simply use "buster" as the distribution here, and go ahead; 
thanks.


Regards,

Adam

Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval


Control: tags -1 + moreinfo

On 2019-07-13 01:19, Sergei Golovan wrote:

I'd like to fix #931422 (see [1]) for buster (the bug is already fixed
in unstable and prospectively in testing).

The diff with the current 1:1.4.8+dfsg-1 is attaced, it's fairly small.


What are the implications of the change on functionality and consumers 
of the library?


Also, I'd like to ask if I should make a source-only or binary upload 
to

stable (and/or oldstable) now?


Source-only would be preferred, so long as the .changes filename is 
sensible (i.e. *not* _amd64.changes when no amd64 binaries are actually 
included).


If the issue also affects stretch and you would like to update the 
package there, please open a separate appropriately-tagged request to 
discuss that.


Regards,

Adam

Bug#933093: [Pkg-fonts-devel] Bug#933093: fonts-mononoki: please build from source, -> main

2019-07-26 Thread Fabian Greffrath

Am Freitag, den 26.07.2019, 17:56 +0200 schrieb Adam Borowski:
> Is there a reason the font is not built from sources, so it could
> move to main?

Currently, it FTBFS:

$ fontmake -i -o otf -g src/mononoki.glyphs
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs 
source
INFO:glyphsLib.classes:Parsing "src/mononoki.glyphs" file into 
INFO:fontmake.font_project:Interpolating master UFOs from designspace
INFO:mutatorMath:   Generating instance mononoki-Regular.ufo
INFO:mutatorMath:../instance_ufo/mononoki-Regular.ufo:
Errors calculating 122 glyphs: 
A.hex
B.hex
C.hex
Che-cy
D.hex
Delta
E.hex
Ef-cy
Ereversed-cy
Eth
F.hex
Hardsign-cy
Ia-cy
Iu-cy
K
Lslash
Omega
Oslash
Psi
Q
Softsign-cy
U
W
Yeru-cy
a
a.hex
acute
ampersand
ampersand_ampersand
asterisk
at
b
b.hex
be-cy
beta
c.hex
che-cy
chi
d
d.hex
dagger
daggerdbl
dollar
dotlessi
dotlessj
e
e.hex
ef-cy
epsilon
equal_equal
equal_greater
ereversed-cy
eta
eth
exclam_equal
f
f.hex
five.hex
g
gamma
germandbls
greater_equal
greaterequal
h
hardsign-cy
hyphen_greater
i
ia-cy
increment
integral
iota
iu-cy
j
k
l
lacute
lcaron
ldot
literSign
lslash
m
multiply
n
omega
onefraction
onetenth
ordfeminine
oslash
p
paragraph
partialdiff
phi
pi
plus
psi
q
question
quotedbl
quotereversed
r
s
sigma
six
softsign-cy
sterling
summation
t
tau
theta
trademark
u
uniE0A2
v
ve-cy
w
x
xi
y
yeru-cy
ze-cy
zero
zeta
INFO:mutatorMath:   Generating instance mononoki-Bold.ufo
INFO:mutatorMath:../instance_ufo/mononoki-Bold.ufo:
Errors calculating 122 glyphs: 
A.hex
B.hex
C.hex
Che-cy
D.hex
Delta
E.hex
Ef-cy
Ereversed-cy
Eth
F.hex
Hardsign-cy
Ia-cy
Iu-cy
K
Lslash
Omega
Oslash
Psi
Q
Softsign-cy
U
W
Yeru-cy
a
a.hex
acute
ampersand
ampersand_ampersand
asterisk
at
b
b.hex
be-cy
beta
c.hex
che-cy
chi
d
d.hex
dagger
daggerdbl
dollar
dotlessi
dotlessj
e
e.hex
ef-cy
epsilon
equal_equal
equal_greater
ereversed-cy
eta
eth
exclam_equal
f
f.hex
five.hex
g
gamma
germandbls
greater_equal
greaterequal
h
hardsign-cy
hyphen_greater
i
ia-cy
increment
integral
iota
iu-cy
j
k
l
lacute
lcaron
ldot
literSign
lslash
m
multiply
n
omega
onefraction
onetenth
ordfeminine
oslash
p
paragraph
partialdiff
phi
pi
plus
psi
q
question
quotedbl
quotereversed
r
s
sigma
six
softsign-cy
sterling
summation
t
tau
theta
trademark
u
uniE0A2
v
ve-cy
w
x
xi
y
yeru-cy
ze-cy
zero
zeta
INFO:mutatorMath:   Generating instance mononoki-Italic.ufo
INFO:mutatorMath:../instance_ufo/mononoki-Italic.ufo:
Errors calculating 122 glyphs: 
A.hex
B.hex
C.hex
Che-cy
D.hex
Delta
E.hex
Ef-cy
Ereversed-cy
Eth
F.hex
Hardsign-cy
Ia-cy
Iu-cy
K
Lslash
Omega
Oslash
Psi
Q
Softsign-cy
U
W
Yeru-cy
a
a.hex
acute
ampersand
ampersand_ampersand
asterisk
at
b
b.hex
be-cy
beta
c.hex
che-cy
chi
d
d.hex

Bug#932009: buster-pu: package gcab/1.2-3


Control: tags -1 + moreinfo

On 2019-07-13 15:52, Stephen Kitt wrote:

Package: release.debian.org
Severity: normal
Tags: stretch


I assumed you meant buster here and fixed that up.


Would it be possible to consider a stable update to gcab 1.2-3 (or its
equivalent as a stable upload)? It fixes a data corruption bug,
#913487; that’s the only change between 1.2-2, which is in Buster, and
1.2-3, which is in Bullseye. The debdiff is as follows:

diff -Nru gcab-1.2/debian/changelog gcab-1.2/debian/changelog
--- gcab-1.2/debian/changelog   2018-12-22 12:37:31.0 +0100
+++ gcab-1.2/debian/changelog   2019-07-06 10:18:07.0 +0200
@@ -1,3 +1,10 @@
+gcab (1.2-3) unstable; urgency=medium


While this is probably fine, please could we have a debdiff versioned as 
1.2-2+deb10u1 (or 1.2-3~deb10u1 if you prefer and it is exactly the same 
content as -3), using a changelog distribution of "buster" and built / 
prepared on buster?


Regards,

Adam

Bug#931608: buster-pu: package cloudkitty/8.0.0-4


Control: tags -1 + confirmed

On 2019-07-08 05:30, Thomas Goirand wrote:

The attached debdiff fixes the FTBS. Details are in the relevant bugs
(as per the debian/changelog). Please allow me to upload the fix to
Buster.


The metadata for #930996 is currently a bit unhelpful, as it only has 
8.0.0-5 as a fixed version, which isn't part of the changelog of the 
package in unstable. I've verified that the fix is included in the 
unstable package, so please feel free to go ahead with the upload, but 
it would be helpful to add a fixed version for whichever point in the 
9.X packages the fix was first introduced.


Regards,

Adam

Bug#932522: buster-pu: package pam-u2f/1.0.7-1


Control: tags -1 + moreinfo

On 2019-07-20 11:15, Nicolas Braud-Santoni wrote:

Control: block 930047 by -1

Here is an updated debdiff; the only modification is in the changelog,
as I forgot to close #930047 there.


+  * Backport a reliability fix
+pam-u2f could previously segfault following a failure to allocate a 
buffer.


I assume this is backported from the version of the package currently in 
unstable?


+pam-u2f (1.0.7-1+deb10u1) buster-proposed-updates; urgency=high

Just "buster", please.

Regards,

Adam

Bug#932448: buster-pu: package dehydrated/0.6.2-2+deb10u1


Control: tags -1 + confirmed

On 2019-07-19 10:10, Mattia Rizzolo wrote:

I'm seeking approval to do this update in buster.
The goal is fixing a set of bugs stemming from upcoming changes on the
Let's Encrypt API.
See:
https://github.com/lukas2511/dehydrated/pull/648
https://github.com/lukas2511/dehydrated/issues/650
https://github.com/lukas2511/dehydrated/issues/647
https://github.com/lukas2511/dehydrated/issues/652

The original fix caused a couple of regression, so it's splitted in 3
commits (→ 3 patch files).
The changes are already in bullseye.


Please go ahead; thanks.

Regards,

Adam

Bug#932335: buster-pu: package facter/3.11.0-2+deb10u1


Control: tags -1 + confirmed

On 2019-07-17 18:45, Apollon Oikonomopoulos wrote:

I would like to update facter in Buster to fix #918250, whereby facter
fails to parse routes with the `onlink' flag, producing a lot of noise
in the process and possibly acquiring a distorted view of the network.
ifupdown adds the `onlink' flag to gateway routes by default, so this
tends to affect a lot of systems.

The issue has been fixed upstream, and backporting the fix is trivial —
in fact I have already uploaded a fixed version in unstable. Full 
source

debdiff against buster attached.


Please go ahead; thanks.

Regards,

Adam

Bug#933110: pkg-components: No upstream maintainer ⇒ unsuitable for Bullseye

Package: pkg-components
Version: 0.11
Severity: serious

Hi,

The Debian Perl group has, somewhat unwillingly, inherited the role of
upstream maintainer for this native package, when its original author
stopped taking care of it. We don't feel we're in a good position to
wear this hat and would rather not to.

Therefore, we decided at the pkg-perl BoF today at DebConf that we
don't want this package to be included in Bullseye, unless someone
else steps up and becomes its upstream maintainer.

I'll file bugs against all reverse-dependencies to alert their
maintainer about this situation.

Cheers,
-- 
intrigeri

Bug#931596: buster-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1


Control: tags -1 + confirmed

On 2019-07-22 02:23, Xavier wrote:

Control: tags - moreinfo

Le 22/07/2019 à 01:31, Jonathan Wiltshire a écrit :

[...]

On Mon, Jul 08, 2019 at 07:04:20AM +0200, Xavier Guimard wrote:

[...]
Your metadata above, bug title, and changelog target all disagree 
about

whether you're targetting buster or stretch or sid. Which is it?


--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libjavascript-beautifier-perl (0.25-1+deb10u1) unstable; 
urgency=medium


Sorry,

title was already fixed, here is the debdiff fix for buster


Fixing it in this mail thread too.

Please go ahead; thanks.

Regards,

Adam

Bug#933109: package-supports-alternative-init-but-no-init.d-script produces too many false positives

2019-07-26 Thread Michael Biebl

Package: lintian
Version: 2.16.0
Severity: normal

Hi,

this is a follow-up to #931889.
This bug report has been marked as fixed by downgrading the severity
from important to minor.

The underlying issue is still, that this test is currently way too
primitive and produces too many false positives to be actually useful.
In #931889 I already listed some cases, where those false-positives are
triggered.

Regards,
Michael


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

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

Versions of packages lintian depends on:
ii  binutils   2.32.51.20190707-1
ii  bzip2  1.0.6-9.2
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.37-4
ii  gettext0.19.8.1-9
ii  gpg2.2.17-3
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.44-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdigest-sha-perl 6.02-1+b1
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.74-1
ii  libipc-run-perl20180523.0-1
ii  liblist-compare-perl   0.53-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libmoo-perl2.003004-2
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  libtype-tiny-perl  1.004004-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.79+repack-2
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

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

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

-- no debconf information

Bug#931832: If you need sponsoring please talk to me

2019-07-26 Thread Коля Гурьев

26.07.2019 13:26, Andreas Tille пишет:
> I do not know who else is working on the repository but I consider it
> overly complex to have several branches and the one with debian in the
> name not containing any debian/ folder.  I wished people would maintain
> some kind of default repository layout to let others immediately know
> what might be happening.

Even if one person is working on the package, it makes sense to use
isolated feature branches. In this case code review is possible, and Git
history is more transparent.

The rlottie package isn't released yet, and so the debian/master branch
is empty. Once the package gets uploaded, its relevant code will be
merged into the main branch.

> I confirm that I also get 
> 
> gbp:error: Error creating rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz: 
> Pristine-tar couldn't checkout 
> "rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz": xdelta: expected from file 
> (/tmp/pristine-tar.UVXpmzNnnT/recreatetarball) of length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.UVXpmzNnnT/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.vZRVhMOe2a/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.LB2mLbYQva/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.LB2mLbYQva/recreatetarball) of 
> length 12779520 bytes
> pristine-tar: Failed to reproduce original tarball. Please file a bug report.

I've already reported this Bug#933031.

> Upstream is meanwhile at 0~git20190725.d07040d .

I see. I had been starting to work on the package last Friday before the
upstream library got this update. Give me some time to stabilize code
base. Please be patient.

Bug#933107: ruby-rubymail: Deprecation warnings with Ruby 2.4 (constant ::Fixnum is deprecated)

2019-07-26 Thread Gerald Turner

Control: tags -1 patch

Attached is a trivial patch which s/Fixnum/Integer/.  I've tested it
with the feed2imap program (from feed2imap package).

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
Ruby 2.4 emits deprecation warnings for use of Fixnum (see
https://bugs.ruby-lang.org/issues/12739)
Index: ruby-rubymail-1.1.3/lib/rmail/header.rb
===
--- ruby-rubymail-1.1.3.orig/lib/rmail/header.rb
+++ ruby-rubymail-1.1.3/lib/rmail/header.rb
@@ -136,10 +136,10 @@ module RMail
 end
 
 # Return the value of the first matching field of a field name, or
-# nil if none found.  If passed a Fixnum, returns the header
+# nil if none found.  If passed a Integer, returns the header
 # indexed by the number.
 def [](name_or_index)
-  if name_or_index.kind_of? Fixnum
+  if name_or_index.kind_of? Integer
 temp = @fields[name_or_index]
 temp = temp.value unless temp.nil?
   else
Index: ruby-rubymail-1.1.3/lib/rmail/parser/pushbackreader.rb
===
--- ruby-rubymail-1.1.3.orig/lib/rmail/parser/pushbackreader.rb
+++ ruby-rubymail-1.1.3/lib/rmail/parser/pushbackreader.rb
@@ -81,11 +81,11 @@ module RMail
 end
   end
   chunk
-when Fixnum
+when Integer
   read_chunk(size)
 else
   raise ArgumentError,
-"Read size (#{size.inspect}) must be a Fixnum or nil."
+"Read size (#{size.inspect}) must be a Integer or nil."
 end
   end
 
@@ -102,7 +102,7 @@ module RMail
   # convenient to call from derived classes when super() isn't
   # easy to use.
   def standard_read_chunk(size)
-unless size.is_a?(Fixnum) && size > 0
+unless size.is_a?(Integer) && size > 0
   raise ArgumentError,
 "Read size (#{size.inspect}) must be greater than 0."
 end
@@ -133,10 +133,10 @@ module RMail
   # Set the chunk size of this reader in bytes.  This is useful
   # mainly for testing, though perhaps some operations could be
   # optimized by tweaking this value.  The chunk size must be a
-  # Fixnum greater than 0.
+  # Integer greater than 0.
   def chunk_size=(size)
-unless size.is_a?(Fixnum)
-  raise ArgumentError, "chunk size must be a Fixnum"
+unless size.is_a?(Integer)
+  raise ArgumentError, "chunk size must be a Integer"
 end
 unless size >= 1
   raise ArgumentError, "invalid size #{size.inspect} given"


signature.asc
Description: PGP signature

Bug#932606: buster-pu: package node-mixin-deep/1.1.3-3+deb10u1


Control: tags -1 + confirmed

On 2019-07-21 04:35, Xavier Guimard wrote:

node-mixin-deep is vulnerable to prototype pollution (#932500,
CVE-2019-10746). Here is a proposed update.


Please go ahead.

Regards,

Adam

Bug#932845: TS-219 RTC issue with Debian Buster

2019-07-26 Thread Oliver Hartkopp

On 26/07/2019 20.12, Trent Piepho wrote:

On Fri, 2019-07-26 at 12:53 +0200, Oliver Hartkopp wrote:

Just a thought:

There are some of these rtc drivers that set

rtc->rtc->uie_unsupported = 1;

in the case that they can't assign an irq line.

But others set

rtc->rtc->uie_unsupported = 1;

when they don't support an (alarm) trigger with 1 sec accuracy.

Wouldn't it make sense to put

+ select RTC_INTF_DEV
+ select RTC_INTF_DEV_UIE_EMUL

in the Kconfig entries of the latter devices?

The hwclock in busybox does not use UIE. Is it the util-linux version
that uses it? Or systemd timedate?

Yes, it is the util-linux version that invokes ioctl(rtc_fd, RTC_UIE_ON,
0), see:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/hwclock-rtc.c#n244

I documented the effect here:
https://marc.info/?l=linux-arm-kernel=156390875629259=2

I know that chrony's linux RTC support requires UIE, or UIE emulation,
to work. chrony does not detect lack of this very well and the RTC
support just "doesn't happen" with no errors. I had to strace it to
figure out it was waiting for UIE interrupts that never came.

"or UIE emulation" - sounds like a plan :-)

Anyway, you don't really need UIE at all to use an rtc in a number of
ways. The kernel "rtc to system clock on boot" feature doesn't need
it.

Right - for that reason the kernel sets the correct time when the
rtc-s35390a driver is built-in.

When its loaded later as a module, the tool hwclock is used to retrieve
the time which fails due to the missing UIE.

The kernel auto sync the rtc every 11 mins from NTP synced system
clock feature doesn't need it. busybox hwclock doesn't need it.

So I suspect it's optional because it's not always needed.

hwclock works great in 'setting' the rtc (hwclock --systohc) but it
fails to read it.

Regards,
Oliver

Bug#900117: Add systemd service file

2019-07-26 Thread Michael Biebl

Hi Bill

Am 22.07.19 um 16:49 schrieb Bill Allombert:
> On Mon, Jul 22, 2019 at 03:35:42PM +0200, Michael Biebl wrote:
>> Hi Bill
>>
>> Am 18.07.19 um 22:56 schrieb Bill Allombert:
>>> Hello Michael,
>>>
>>> Sorry for the delay.
>>>
>>> I have added your .service file to the upstream package.
>>> However for Debian, how does this will interact with options
>>> set in /etc/default/consolation ?
>>
>> I personally consider /etc/default/$foo as a (Debian specific) sysvinit
>> anachronism and prefer if this is only used by the SysV init script.
>>
>> systemd provides a native mechanism to extend or override parts of a
>> service, called systemd drop-in files [1], which is the preferred way if
>> you want to customize the service.
>>
>> If you want to be nice to your users, you can add a note to
>> /etc/default/consolation that this file is SysV init specific.
> 
> Well but then users who upgrade will lose their configuration, which is
> opposite to Debian principles on upgrade.

I would be pragmatic here.
If you expect that a high percentage of your users has modified
/etc/default/consolation as they needed to change the daemon parameters,
then I would do a one-time migration of those settings in postinst.
Otherwise I would just document this change, either via changelog.Debian
or NEWS.Debian.

Regards,
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#932900: buster-pu: package freetype 2.9.1-4


Control: tags -1 + confirmed d-i

On 2019-07-24 10:45, Hugh McMaster wrote:

Package: release.debian.org
Severity: normal
Tags: patch


Please either set the metadata appropriately here to indicate a stable 
update, or use reportbug which will do it for you. (In this case, 
someone already corrected it.)


FreeType versions 2.9 to 2.10.1 have rendering problems with variable 
hinted
fonts. In specific cases, such as with the Oswald typeface, glyphs do 
not scale

correctly and end up appearing on top of each other.

This bug affects Chromium 76 and later versions, as that browser uses 
FreeType

for variable hinted fonts. Firefox is also affected.

Google Fonts states that Oswald is used on 8.3M websites.

Given that Chromium and Firefox are affected, and the significant 
presence of
variable hinted fonts in use on the internet and elsewhere, I am 
requesting

freetype 2.9.1-4 be considered for the next point release of Buster.


-4 has already been uploaded to unstable, so this would need to be 
2.9.1-3+deb10u1. The changelog distribution is also preferred as 
"buster", rather than "stable".


As freetype produces a udeb, this will need an ack from the d-i release 
manager, so CCing and tagging appropriately.


Regards,

Adam

Bug#933108: id-utils should build verbosely

Source: id-utils
Version: 4.6.21+20171216ss6cdfd-1
Tags: patch

id-utils fails to cross build from source, but debugging why is too
hard to figure out, because the compiler invocations are hidden. The
configure script defaults to --enable-silent-rules. That's not what the
Debian policy recommends. Please pass --disable-silent-rules unless
DEB_BUILD_OPTIONS contains the "terse" option. The attached patch
implements that. Alternatively, consider using dh_auto_configure. Either
way, please make the build verbose by default.

Helmut

Bug#922466: whitelist not working on python3 (buster version)

2019-07-26 Thread Hugo Lefeuvre

Hi,

Sorry for overlooking this issue. This should be fixed in the next pyzor
upload, in the next few days.

Thanks for reporting this.

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#933107: ruby-rubymail: Deprecation warnings with Ruby 2.4 (constant ::Fixnum is deprecated)

2019-07-26 Thread Gerald Turner

Package: ruby-rubymail
Version: 1.1.3-3
Severity: minor

Dear Maintainer,

Executing feed2imap (feed2imap package) produces the following error
output:

  /usr/lib/ruby/vendor_ruby/rmail/header.rb:142: warning: constant ::Fixnum is 
deprecated

Ruby 2.4 added a deprecation warning for the constant "Fixnum", see:

  https://bugs.ruby-lang.org/issues/12739

Evidently Fixnum can be replaced by Integer throughout the rubymail
source.

Warning: I am not a Ruby programmer, so I may be interpreting this
wrong.

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

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

Versions of packages ruby-rubymail depends on:
ii  ruby  1:2.5.1

ruby-rubymail recommends no packages.

ruby-rubymail suggests no packages.

-- no debconf information

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

2019-07-26 Thread Hilmar Preuße


Am 26.07.2019 um 07:24 teilte Norbert Preining mit:

On Thu, 25 Jul 2019, Hilmar Preuße wrote:


Hi,


dvisvgm build (and links) fine on Hurd. We have a failure in the test
suite. I'll care about that later on.


Ok, please check that


I opened a bug @upstream [1] and got a patch for it. I'll commit it to
our repo as soon as -1 has entered the archive.

Hilmar

[1] https://github.com/mgieseki/dvisvgm/issues/116
--
#206401 http://counter.li.org

Bug#933106: d-shlibs: binary not built on buildd.

2019-07-26 Thread Peter Michael Green


Package: d-shlibs
Version: 0.85
Severity: serious

The release team have decreed that binaries not built on buildds can no 
longer migrate to testing. Please make a source only upload so the fix 
for 932632 can migrate to testing.

Bug#925656: Triage

2019-07-26 Thread Giovanni Mascellani

Hi,

I cannot reproduce the bug, but I believe that changing line 332 of
src/graphics/model/model_output.cpp from

  strncpy(t.texName, triangle.tex1Name.c_str(), sizeof(t.texName)-1);

to

  strncpy(t.texName, triangle.tex1Name.c_str(), sizeof(t.texName));

should send away the warning without changing the result (apart from
possibly requiring a couple of additional cycles at execution time).
Otherwise one might just change compilation flags in order not to treat
warnings as fatal, which is often rather exaggerate.

HTH, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#933103: vdr-plugin-remote FTCBFS: uses the build architecture pkg-config

Source: vdr-plugin-remote
Version: 0.7.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vdr-plugin-remote fails to cross build from source, because it uses the
build architecture pkg-config. The attached patch makes it substitutable
and exports a PKG_CONFIG for all targets as only dh_auto_build supplies
it normally. Please consider applying it.

Helmut
diff --minimal -Nru vdr-plugin-remote-0.7.0/debian/changelog 
vdr-plugin-remote-0.7.0/debian/changelog
--- vdr-plugin-remote-0.7.0/debian/changelog2019-07-20 05:34:59.0 
+0200
+++ vdr-plugin-remote-0.7.0/debian/changelog2019-07-26 20:34:54.0 
+0200
@@ -1,3 +1,10 @@
+vdr-plugin-remote (0.7.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 26 Jul 2019 20:34:54 +0200
+
 vdr-plugin-remote (0.7.0-3) unstable; urgency=medium
 
   * Build-depend on vdr-dev >= 2.4.1
diff --minimal -Nru vdr-plugin-remote-0.7.0/debian/patches/cross.patch 
vdr-plugin-remote-0.7.0/debian/patches/cross.patch
--- vdr-plugin-remote-0.7.0/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ vdr-plugin-remote-0.7.0/debian/patches/cross.patch  2019-07-26 
20:34:53.0 +0200
@@ -0,0 +1,12 @@
+--- vdr-plugin-remote-0.7.0.orig/Makefile
 vdr-plugin-remote-0.7.0/Makefile
+@@ -31,7 +31,8 @@
+ 
+ ### The directory environment:
+ # Use package data if installed...otherwise assume we're under the VDR source 
directory:
+-PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) 
$(VDRDIR)/vdr.pc),$(shell pkg-config --variable=$(1) vdr || pkg-config 
--variable=$(1) ../../../vdr.pc))
++PKG_CONFIG ?= pkg-config
++PKGCFG = $(if $(VDRDIR),$(shell $(PKG_CONFIG) --variable=$(1) 
$(VDRDIR)/vdr.pc),$(shell $(PKG_CONFIG) --variable=$(1) vdr || $(PKG_CONFIG) 
--variable=$(1) ../../../vdr.pc))
+ LIBDIR = $(DESTDIR)$(call PKGCFG,libdir)
+ LOCDIR = $(DESTDIR)$(call PKGCFG,locdir)
+ PLGCFG = $(call PKGCFG,plgcfg)
diff --minimal -Nru vdr-plugin-remote-0.7.0/debian/patches/series 
vdr-plugin-remote-0.7.0/debian/patches/series
--- vdr-plugin-remote-0.7.0/debian/patches/series   2019-07-20 
05:34:59.0 +0200
+++ vdr-plugin-remote-0.7.0/debian/patches/series   2019-07-26 
20:34:21.0 +0200
@@ -1 +1,2 @@
 disable-po-update.patch
+cross.patch
diff --minimal -Nru vdr-plugin-remote-0.7.0/debian/rules 
vdr-plugin-remote-0.7.0/debian/rules
--- vdr-plugin-remote-0.7.0/debian/rules2019-07-20 05:34:59.0 
+0200
+++ vdr-plugin-remote-0.7.0/debian/rules2019-07-26 20:34:54.0 
+0200
@@ -2,6 +2,8 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+-include /usr/share/dpkg/buildtools.mk
+export PKG_CONFIG ?= pkg-config
 
 %:
dh $@ --with vdrplugin

Bug#933105: makebootfat FTBFS when /etc/mtab does not exist

Source: makebootfat
Version: 1.4-6
Severity: serious
Tags: ftbfs

makebootfat fails to build from source when /etc/mtab does not exist,
because it tries to create it and fails due to missing permissions. This
happens to be the case on the official buildds:
https://buildd.debian.org/status/fetch.php?pkg=makebootfat=amd64=1.4-6=1564010526=0

Helmut

Bug#933066: ruby-gnome2: autopkgtest regression with GLib 2.60.x: format_size now uses non-breaking space

2019-07-26 Thread Paul Gevers

Control: affects -1 src:gst-plugins-good1.0

Hi,

On 26-07-2019 12:39, Simon McVittie wrote:
> Source: ruby-gnome2
> Version: 3.3.2-1
> Severity: serious
> Justification: 
> https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
> Tags: upstream fixed-upstream patch
> Forwarded: 
> https://github.com/ruby-gnome2/ruby-gnome2/commit/ac9762af255f276800e0863d1dd07ab9dd653d1b
> User: debian...@lists.debian.org
> Usertags: regression
> X-Debbugs-CC: debian...@lists.debian.org
> 
> ruby-gnome2's autopkgtest fails when run against GLib 2.60.x from unstable,
> with 7 failures all similar to this:
> 
> Failure: test_gb(TestGLibFileUtils::#format_size)
> /tmp/autopkgtest-lxc.6g_rx45a/downtmp/build.TEl/src/glib2/test/test-file-utils.rb:61:in
>  `test_gb'
>  58: end
>  59:
>  60: def test_gb
>   => 61:   assert_equal("1.0 GB", GLib.format_size(1000 * 1000 * 1000))
>  62: end
>  63:
>  64: def test_over_guint32_value
> <"1.0 GB"> expected but was
> <"1.0 GB">
> 
> I think the difference here is that the expected result has a space but
> the actual result has a UTF-8 non-breaking space (U+00A0 NO-BREAK SPACE)
> as a result of https://gitlab.gnome.org/GNOME/glib/issues/1625 having
> been fixed. This is a bit more obvious in the Python bindings:
> 
> $ python3
 from gi.repository import GLib
 GLib.format_size(1000*1000*1000)
> '1.0\xa0GB'
> 
> This appears to have been fixed upstream in
> https://github.com/ruby-gnome2/ruby-gnome2/commit/ac9762af255f276800e0863d1dd07ab9dd653d1b
> (but note that I haven't tested that patch myself). Please consider
> applying it.
> 
> Thanks,
> smcv
> 

This affects the new version of gst-plugins-good1.0 as well, hence
making the maintainers aware of this bug.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#933104: liblockfile FTCBFS: no longer honours DEB_BUILD_OPTIONS=nocheck